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Abstract 


A  programming  tool,  the  Graph  Design  Assistant  (GDA), 
for  a  special-purpose  dataflow  language  was  designed  and 
implemented.  The  motivation  for  the  effort  was  the  need  to 
construct  a  robot  simulation  facility  which  will  assist  in 
the  development  of  effective  algorithms  to  plan  and  control 
robot  movements. 

An  Evans  and  Sutherland  PS300  graphic  workstation  is 
used  to  display  animated  robot  simulations.  The  Graph 
Design  Assistant  was  developed  so  that  researchers  could 
program  robot  simulations  on  the  PS300  without  having  to 
learn  the  intricacies  of  the  PS300's  dataflow  language. 

The  Graph  Design  Assistant  was  implemented  on  a  "Lisp 
machine"  using  a  knowledge  engineering  tool.  The  result  of 
the  effort  was  a  prototype  system  to  be  used  as  the  basis 
for  further  development. 


A  PROGRAMMER'S  ASSISTANT  FOR  A  SPECIAL-PURPOSE 
DATAFLOW  LANGUAGE 


I.  Introduction 


This  thesis  describes  an  investigation  into  the 
methodology  of  computer  programming.  There  is  a  critical 
need  to  increase  the  power  of  our  programming  tools.  John 
Backus  has  stated  "there  is  a  desperate  need  for  a  powerful 
methodology  to  help  us  think  about  programs,  and  no 
conventional  language  even  begins  to  meet  that  need" 

(Backus,  1978:614). 

This  thesis  deals  with  a  specialized  problem, 
programming  a  graphic  work  station  using  a  special-purpose 
dataflow  language.  The  result  of  the  thesis  effort  was  the 
development  of  the  Graph  Design  Assistant  (GDA).  The  system 
acts  as  a  programmer's  assistant,  which  guides  and  advises 
the  programmer  as  he  interactively  builds  a  dataflow 
program. 

Although  GDA  was  intended  to  solve  a  rather  specific 
problem,  the  experience  gained  and  the  resulting  system  is 
applicable  to  many  complex  design  tasks. 


1.1  Background--A  Robot  Simulation  Facility 


The  motivation  for  this  thesis  effort  is  to  provide  a 
robot  simulation  facility  for  the  Air  Force  Institutes  of 
Technology's  Information  Sciences  Laboratory.  The  ability 
to  simulate  a  robot  is  important  for  the  development  of 
robotic  planning  and  control  algorithms,  the  development  of 
new  robots,  and  for  off-line  programming  of  existing  robots. 

Current  robots  can  perform  well  defined  tasks,  but 
perform  poorly  in  uncontrolled  environments  (Brady  1985:80- 
81).  A  robot  simulation  can  be  useful  in  the  development  of 
robotic  control  and  planning  algorithms  to  deal  with  complex 
situations..  A  simulation  facility  would  make  it  possible 
to  test  algorithms  without  having  to  actually  build  a 
physical  robot. 

A  robot  simulation  facility  can  be  used  in  the 
development  of  new  robots.  Different  designs  can  be  tested 
before  the  actual  robot  is  constructed. 

A  simulation  facility  is  even  useful  for  existing 
robots.  Control  programs  for  existing  robots  can  be 
developed  and  tested  off-line  (independent  of  the  existing 
robot).  This  capability  will  be  important  in  industry 
because  it  can  prevent  losses  caused  by  removing  an 
expensive  robot  from  service  in  order  to  program  it 
(Thomsom,  1984:335-336).  In  addition,  because  software 
errors  may  cause  hazardous  situations  with  a  real  robot,  a 


simulation  can  be  used  to  thoroughly  test  new  software  in  a 
safe  environment  (Pinson,  1985). 


1.2  Problem 


The  specific  problem  addressed  by  this  thesis  effort  is 
the  development  of  a  programming  tool  for  constructing 
special-purpose  dataflow  programs.  The  dataflow  language  is 
a  special-purpose  language  used  to  program  an  Evans  and 
Sutherland  PS300  graphic  workstation. 

Thus,  the  objective  is  to  allow  researchers  to  program 
a  robot  simulation  on  the  PS300  without  having  to  learn  the 
intricacies  of  the  PS300's  dataflow  language. 

1.3  Scope 

The  task  of  producing  a  general  purpose  automatic 
programming  system  is  difficult.  Most  of  the  existing 
efforts  are  experimental  and  are  capable  of  solving  small 
problems  (Partsch,  1983:  229).  One  effort  has  been  underway 
for  15  years  and  has  just  recently  produced  an  "operational 
testbed"  (Balzer,  1985:1257).  Rather  than  attempting  to 
fulfill  "that  ever  receding  goal  of  automating  the 
programming  of  everything  the  user  wants  with  a  minimal 
amount  of  specification"  (Kant,  1985:1371),  the  scope  of  the 
Graph  Design  Assistant  was  limited  in  several  ways. 


The  product  of  GDA  is  a  program  in  the  special-purpose 
dataflow  language.  Dataflow  programs  are  easily  represented 
with  graphs;  therefore,  a  graphic  representation  was  devised 
for  the  user  to  manipulate. 

The  application  domain  has  been  limited  to  producing 
robot  simulations.  This  restriction  is  not  unreasonable,  in 
fact,  it  has  been  suggested  that  in  order  for  an  automatic 
programming  system  to  benefit  the  "computationally  naive 
user",  the  system  must  contain  domain-specific  knowledge 
(Barstow,  1985:1321). 

Another  limitation  on  the  scope  of  the  effort  is  that 
the  initial  version  of  the  Graph  Design  Assistant  is  viewed 
as  a  prototype.  One  view  of  prototyping  is  that  its  purpose 
is  to  produce  a  specification  for  a  system  (Floyd,  1984:9). 
As  such,  this  effort  was  to  produce  a  complete  "outline"  of 
the  system  that  will  demonstrate  feasibility  and  serve  as  a 
specification  for  further  development. 

1.5  General  Approach 

The  approach  in  the  development  of  the  Graph  Design 
Assistant  was  to  focus  on  the  construction  of  an  interactive 
tool  that  is  a  "mix  of  human  and  machine  power"  (Kant, 
1985:1373).  The  system  is  was  designed  to  fit  somewhere 
between  the  extremes  of  conventional  compilers  and  fully 
automatic  programming  systems. 
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In  the  interactive  environment  of  the  Graph  Design 
Assistant,  the  user  specifies  a  program  by  building  a  graph 
on  the  screen.  As  the  graph  is  built,  GDA  checks  the 
"consistency"  of  the  graph  and  notifies  the  user  of  any 
problems. 

With  GDA,  much  of  the  programming  process  involves  the 
selection  of  "plans"  from  a  library.  The  term  plan  is  used 
to  mean  a  "standard  form"  (Rich,  1981:1044).  A  plan  is 
instantiated  and  then  expanded  (like  a  macro)  to  form  a 
portion  of  the  graph.  At  the  top  of  Figure  1.1  is  a  graph 
network  with  nodes  Nl,  N2,  N3,  and  N5.  The  user  has 
selected  a  plan  PLAN-4  a  placed  it  in  the  network.  When  the 
plan  is  instantiated,  it  "unfolds"  to  create  the  graph  at 
the  bottom  of  Figure  1.1. 

There  are  many  different  approaches  to  the  development 
of  programming  tools.  Some  approaches  are  similar  but  are 
described  with  different  terms  by  their  designers.  What 
follows  is  a  comparison  and  contrast  between  several 
approaches  and  the  Graph  Design  Assistant. 

Conventional  programming  tools.  Conventional 
programming  tools  consist  of  high  level  compilers  and 
interpreters,  and  utilities  such  as  program  editors,  library 
managers,  debuggers,  etc.  Of  all  the  approaches  that  will 
be  discussed,  the  conventional  approach  relies  most  on  the 
user’s  decisions. 
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Figure  1.1  Plan  Instantiation  Example 


Compilers  have  been  developed  specifically  for  dataflow 
computers  that  accept  a  language  similar  to  ordinary 
procedural  languages  (Ackerman,  1982:15-16;  Veen,  1981:130). 
There  has  been  one  effort  to  develop  a  compiled  language 
specifically  for  the  Evans  and  Sutherland  PS300  (Yamaguchi, 
1985:48-60).  Although  this  may  benefit  the  user  who  is 
familiar  with  the  PS300,  it  would  still  require  considerable 
effort  for  a  new  user  to  learn  the  language.  An  objective 
of  the  Graph  Design  Assistant  is  to  allow  a  user  to  use  the 
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PS300  without  having  to  learn  the  syntax  of  a  textual 
language. 

Program  Transformation  Systems.  Program  transformation 
systems  form  a  broad  category  of  programming  tools. 
"Transformational  programming  is  a  methodology  of  program 
construction  by  successive  applications  of  transformation 
rules"  (Partsch,  1983:201).  The  instantiation  of  a  plan  in 
the  Graph  Design  Assistant  can  be  viewed  as  applying  a 
transformation  to  the  functional  network  graph.  In  some  of 
the  program  transformation  systems  the  user  selects  trans¬ 
formations  from  libraries  or  catalogs  (Partsch,  1983:206). 
This  is  similar  to  the  selection  of  plans  in  GDA. 

Programmer's  Apprentice.  The  Programmer's  Apprentice 
(PA)  is  a  project  developed  at  M. I .T. (Waters ,  1985:1296). 

The  PA  can  be  classified  as  a  program  transformation  system 
(Partsch,  1983:  224).  It  is  included  in  a  separately  in 
this  section  because  its  approach  is  similar  to  that  of  the 
Graph  Design  Assistant.  The  Programmer's  Apprentice  "lies 
somewhere  between  language-oriented  programming  tools  one 
hand,  and  automatic  programming  tools  on  the  other"  (Rich, 
1978:444).  The  Programmer's  Apprentice  is  designed  to 
interactively  aid  and  check  the  work  of  a  programmer;  it 
keeps  track  of  details  and  frees  the  programmer  to 
concentrate  on  the  hard  parts  of  the  problem  (Waters, 
1985:1296). 


Graph  Grammars.  There  has  been  work  in  the  theory  of 
graph  grammars  which  is  relevant  to  the  Graph  Design 
Assistant.  Graph  grammar  theory  is  uses  dimensional  graphs 
in  the  same  way  that  Formal  Language  theory  uses  one 
dimensional  strings  (Ehrig,  1978:9).  It  has  been  suggested 
that  graph  grammars  would  be  useful  in  the  generation  of 
programs,  given  that  so  many  of  the  programming  aids  (flow 
charts,  structure  charts,  block  diagrams,  etc.)  are  in  the 
form  of  graphs  (Nagel,  1979:71).  In  the  case  of  dataflow 
programming  languages,  graph  grammars  are  particularly 
appropriate  because  dataflow  programs  are  easily  represented 
with  graphs  (Davis,  1982:26). 

A  System  for  Interactive  Design  (SID)  is  an  example  of 
a  system  which  uses  a  graph  grammar  as  its  basis  (Kunii, 
1980:33).  SID  has  been  used  to  design  hospital  information 
systems  (Kunii,  1980:33)  and  petrochemical  plants  (Buchmann, 
1979:  732). 

In  the  design  of  the  GDA,  an  attempt  was  made  to  define 
the  grammar  of  the  PS300's  dataflow  language  as  a  separate 
part  of  the  system.  The  objective  of  the  separation  of  the 
grammar  of  the  FGN  language  is  that  the  GDA  system  could  be 
used  for  other  purposes  by  replacing  the  grammar  definition. 

Visual  Programming.  A  recent  term  which  has  been  used 
to  describe  some  programming  systems  is  "visual  programming" 
(Jacob,  1985:51).  The  idea  is  to  construct  programs  by 
creating  and  editing  diagrams  rather  than  text.  Others  have 


stated  that  since  a  dataflow  programs  can  be  viewed  as  a 
graph,  it  would  be  advantageous  to  do  away  with  a  text 
representation  and  directly  manipulate  the  graph  (Davis, 
1982:27). 

The  Graph  Design  Assistant  presents  the  dataflow 
program  to  the  user  in  the  form  of  a  graph.  The  user 
creates  and  edits  programs  by  making  changes  directly  to  the 
graph. 

1.5  Sequence  of  Presentation 

Chapter  II  presents  the  requirements  definition  by 
examining  the  needs  for  a  robot  simulation  facility,  and  for 
the  Graph  Design  Assistant.  The  system  architecture  and 
overall  design  of  the  GDA  is  presented  in  chapter  III.  In 
addition  the  development  strategy  for  GDA  is  described  and 
justified.  Chapter  IV  discusses  the  detail  design  and 
implementation  of  the  Graph  Design  Assistant.  Finally,  the 
results,  conclusions  and  recommendations  are  presented  in 
chapter  VI. 


II.  Requirements  and  High-Level  Design 


The  first  step  in  the  design  of  the  Graph  Design 
Assistant  was  to  define  the  requirements  for  the  system. 
Requirements  are  a  description  of  a  system  to  be  build 
(DeMarco,  1979:412). 

The  first  section  in  this  chapter  is  a  description  of 
the  general  requirements  for  the  robot  simulation  facility 
This  provided  the  context  for  the  Graph  Design  Assistant. 
Next,  the  Functional  Graph  Network  (FGN)  language  is 
examined.  FGN  is  the  desired  output  of  the  Graph  Design 
Assistant;  therefore,  it  is  a  major  factor  in  the 
determination  of  the  performance  requirements  for  GDA. 
Next,  the  specific  requirements  for  the  Graph  Design 
Assistant  are  outlined  with  a  series  of  design  goals. 
Finally,  an  example  scenerio  is  used  to  make  explicit  the 
interactive  user  requirements  of  GDA. 


2.1  General  Requirements  for  a  Robot  Simulation  Facilit 
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Program  Developer,  and  Robot  Model  User.  Figure  2.1  xs  a 
diagram  which  shows  the  three  different  user  roles,  the 
processes  which  comprise  the  system,  and  the  output  from  the 
processes. 

Robot  Display  Designer.  One  function  the  robot 
simulation  facility  must  perform  is  to  allow  for  the 
creation  of  robot  models.  As  shown  in  Figure  2.1  there  are 
two  processes  involved  in  the  creation  of  a  robot  simulation 
model.  They  are  the  Display  Tree  Design  Tool  and  the  Graph 
Design  Assistant. 


USER  ROLE 


OUTPUT 


ROBOT  DISPLAY 
DESIGNER 


ROBOT  CONTROL 
PRO  ORAM  DEVELOPER 


ROBOT  MODEL 
USER 


GRAPH  DESIGN 
ASSISTANT 


DISPLAY  TREE 
DESIGN  TOOL 


ADA  PROGRAMMING 

<  TOOL  > 


FGN  PROGRAM 
'ANIMATE  ROBOT 


DISPLAY  TREE 
■ROBOT  TREE’ 


ADA  PROGRAM 
•CONTROL  ROBOT 


DISPLAY  OF 
ANIMATED  ROBOT 


•CONTROL  ROBOT 


■ANIMATE  ROBOT 


•ROBOT  TREE’ 


Figure  2.1  User  Roles  in  the  Robot  Simulation  Facility 
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The  first  process  used  by  the  Robot  Display  Designer  is 
Display  Tree  Design  Tool.  The  processes  allows  the  user  to 
design  and  edit  display  trees.  A  display  tree  is  a  data 
structure  which  contains  the  three  dimensional  coordinate 
information  which  defines  the  shape  of  the  image.  When  the 
display  tree  is  loaded  into  the  PS300,  the  image  is 
displayed  on  the  PS300's  screen.  In  the  example  shown  in 
Figure  2.1  the  display  tree  is  named  "Robot  Tree";  it 
describes  the  shape  of  a  robot. 

The  second  process  used  by  the  Robot  Display  Designer 
is  the  Graph  Design  Assistant.  With  the  GDA,  the  Robot 
Display  Designer  creates  a  functional  graph  network,  named 
"Animate  Robot"  in  the  example  in  Figure  2.1,  which 
controls  the  movements  of  Robot  Tree. 

The  two  products  created  by  the  Robot  Display  Designer, 
together  define  the  animated  robot  model.  When  loaded  into 
the  Evans  and  Sutherland  PS300,  the  display  tree  defines  a 
three  dimensional  image  of  a  robot,  and  the  functional 
network  controls  the  movement  of  the  robot. 

In  the  example  shown  in  Figure  2.1,  the  robot  model  is 
designed  to  interface  to  a  robot  control  program  running  on 
the  host  computer  connected  to  the  PS300.  It  should  be 
noted,  however,  that  it  is  possible  to  design  robot  models 
that  are  controlled  directly  through  input  devices  on  the 
PS300.  The  assumption  in  the  example  is  that  the  users  of 


the  robot  simulation  facility  have  an  interest  in  developing 
robot  planning  and  control  programs. 

Robot  Control  Program  Developer.  Another  role  that  a 
user  of  the  robot  simulation  facility  might  assume  is  that 
of  a  Robot  Control  Program  Developer.  In  Figure  2.1,  the 
Robot  Control  Program  Developer  is  using  an  Ada  programming 
tool  to  develop  a  program  named  Control  Robot.  (The  program 
language  Ada  was  choosen  as  an  example,  in  fact,  other 
programming  languages  could  be  used  its  place.)  In  Figure 
2.1  the  robot  simulation  model  created  by  the  Robot  Display 
Designer  would  be  used  to  test  the  program  "Control  Robot". 

Robot  Model  User.  The  last  role  defined  for  the  users 
of  the  robot  simulation  facility  is  that  of  the  Robot  Model 
User.  In  this  role  the  user  gives  high  level  commands  to 
"Control  Robot".  The  process  "Control  Robot"  gives  lower 
level  commands  to  "Animate  Robot"  to  cause  the  simulated 
robot's  movements. 

As  can  be  seen  in  Figure  2.1  the  Graph  Design  Assistant 
is  part  of  the  process  used  by  the  Robot  Display  Designer. 
The  purpose  of  GDA  is  to  create  a  functional  network  which 
controls  the  movements  of  the  animated  robot.  The 
functional  network  is  created  using  a  special-purpose 
dataflow  language  named  the  Functional  Graph  Network  (FGN) 
language.  The  next  section  describes  this  language. 


2.2  Functional  Graph  Network  Language 


The  Functional  Graph  Network  (FGN)  language  is  the 
special-purpose  dataflow  language  which  is  used  to  program 
the  Evans  and  Sutherland  PS300  graph  workstation  (Davis, 
1984).  A  FGN  program  consists  of  a  series  of  statements 
which  are  instructions  to  the  PS300  to  construct  functional 
networks  and  display  trees  within  the  PS300's  memory.  Once 
a  network  and  display  tree  are  in  memory,  the  PS300  scans 
the  display  tree  and  shows  the  resulting  image  on  the 
display  screen  (Evans  and  Sutherland,  1984a).  The 
functional  network  can  have  connections  to  the  PS300's  input 
devices  (tablet,  dials,  mouse,  and  function  keys),  and  can 
output  data  to  the  display  tree.  In  this  way,  the 
functional  network  allows  the  user  to  manipulate  the  image 
with  the  input  devices.  Additionally,  a  host  computer 
connected  to  the  PS300  can  send  data  to  the  functional 
network  and  manipulate  the  image. 

In  this  section,  a  simple  example  of  a  display  tree,  a 
functional  network,  and  the  FGN  program  which  generates  the 
tree  and  network,  is  developed.  Figure  2.2  illustrates  the 
functional  capabilities  of  the  ’’Rotate  Squares”  example. 
Within  each  of  the  rounded  squares  is  an  image  that  would 
appear  on  the  display  screen  of  the  PS300.  The  left  most 
screen  is  the  initial  image  of  two  concentric  squares. 
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Figure  2.2  Rotate  Squares  Example:  Functional  Capabilities 

Turning  dial  1  causes  both  squares  to  rotate,  while 
turning  dial  2  causes  the  inner  square  to  rotate  relative  to 
the  outer  square.  The  following  section  explains  how  the 
the  display  tree  and  the  functional  network  for  the  "Rotate 
Squares"  example  are  constructed. 


2.2.1  Display  Trees 

A  display  tree  is  a  hierarchical  structure  within  the 
Evans  and  Sutherland  PS300.  The  display  tree  consists  of 
elements  linked  together  in  a  tree  like  structure.  The 
elements  are  vector  lists,  sub-tree  structures,  and 
transformation  nodes.  The  PS300  displays  an  image  by 
constantly  scanning  a  display  tree,  applying  transformations 
in  the  nodes  to  vector  lists  and  displaying  the  resultant 
vectors  on  the  screen. 

Figure  2.3  is  a  diagram  which  represents  the  display 
tree  in  the  "Rotate  Squares"  example.  Starting  at  the  top 
of  the  tree,  the  triangle  is  a  sub-tree  structure  named 
"double-squares".  The  node  labeled  "rot_out"  (labeled  nodes 
are  shown  as  two  concentric  circles)  is  a  transformation 
node  used  to  rotate  the  outer  and  inner  squares.  The 
unlabeled  node  (unlabeled  nodes  are  shown  as  single  circles) 
is  a  transformation  node  used  to  scale  the  inner  square. 

The  node  labeled  "rot_in"  is  a  transformation  node  used  to 
rotate  the  inner  square.  The  box  labeled  "square"  is  a  list 
of  vectors  or  lines  (stored  as  the  end  points  of  each  line) 
that  define  the  4  sides  of  a  square. 

In  the  display  tree  in  Figure  2.3  there  are  two 
"instances"  of  the  square  depicted  as  lines  from  "rot_out" 
and  "rot_in".  The  "rot_out"  transformation  node  is  designed 


so  that  when  a  rotation  transformation  is  applied  to  the 


node,  both  instances  of  the  square  (the  inner  and  outer 
squares)  rotate  together.  The  unlabeled  transformation  node 
directly  below  "rot_out"  contains  a  scaling  transformation 
which  makes  the  inner  square  smaller  than  the  outer  square. 
The  Hrot_in"  transformation  node  is  designed  so  that  when  a 
rotation  transformation  is  applied  to  the  node,  only  the 
inner  square  rotates. 


Figure  2.3  Rotate  Squares  Example:  Display  Tree 


The  image  defined  by  the  display  tree  in  Figure  2.3  can 
manipulated  by  making  connections  from  a  functional  network 
to  the  labeled  nodes.  The  one  transformation  node  is 


V  "I  W  -  v  ^  V 


unlabeled  because  the  scaling  transformation  was  designed  to 
remain  constant;  therefore,  it  does  not  need  a  label  as  a 
connection  point  to  the  functional  network.  The  next 
section  describes  functional  networks  and  how  they  relate  to 
display  trees. 

2.2.2  Functional  Networks 


The  PS300  is  programmed  by  constructing  functional 
networks  that  reside  in  the  PS300's  internal  memory.  The 
functional  networks  of  the  PS300  can  be  viewed  a  dataflow 
graph  (Davis,  1984:1.2).  In  a  dataflow  graph,  the  nodes  of 
the  graph  are  connected  to  each  other  with  arcs.  Data 
tokens  flow  between  the  nodes  on  the  arcs.  Each  node 
performs  a  function  on  its  input  data  tokens  and  produces 
output  data  tokens. 

There  are  many  types  of  functional  nodes  used  in  the 
PS300.  Many  of  the  nodes  perform  functions  designed 
specifically  for  a  graphic  operations.  For  example,  there 
are  functions  which  support  matrix  and  vector  manipulations. 
These  are  useful  for  the  transformation  of  three  dimensional 
coordinate  data.  Other  functions  are  more  general  purpose 
in  nature,  allowing  the  construction  of  general  purpose 
computational  structures.  For  example  there  are  functional 
nodes  which  are  useful  in  building  iterative  loops  (Davis, 
1984:2.13). 
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Several  types  of  data  tokens  which  flow  between  the 
functional  nodes  in  the  network.  The  data  tokens  can  be 
simple  or  composite  date  items.  The  simple  data  items  can 
be  integers,  reals,  or  boolean  values.  The  composite  data 
items  can  be  matrices  or  vectors. 


Figure  2.4  Rotate  Squares  Example:  Functional  Network 


The  functional  network  for  the  "Rotate  Squares"  exampl 


is  shown  in  Figure  2.4  on  the  left  side.  There  are  three 
functional  nodes  (shown  as  boxes),  labeled  "dials", 

"rotate  outer",  and  "rotate  inner".  The  "dials"  functional 


node  is  used  to  get  input  from  the  PS300's  dial  inputs 
(Evans  and  Sutherland,  1984b: 5).  The  PS300  has  a  set  of 
dials  that  the  user  can  turn.  If  the  output  of  a  dial  has 
been  connected  to  a  functional  network,  then  when  the  user 
turns  the  dial,  a  stream  of  real  numeric  data  tokens  are 
sent  out  from  the  functional  node.  In  this  example,  dials  1 
and  2  are  used  as  inputs  to  the  functional  network.  The 
"rotate_outern  and  "rotate_inner"  nodes  are  FrDZROTATE 
type  nodes.  Every  time  a  F:DZROTATE  node  receive  a  numeric 
data  token  on  its  input,  it  applies  a  rotation  about  the  Z 
axis  to  an  internal  transformation  matrix.  This  matrix  is 
then  sent  out  on  output  1  of  the  F:DZROTATE  node.  Since  the 
output  of  "rotate^uter"  and  Mrotate_inner"  are  connected  to 
nodes  in  the  display  tree,  each  time  dial  1  or  2  is  turned 
the  transformation  matrix  in  the  nodes  "rot_out"  or  Mrot_in" 
are  replaced  to  reflect  an  incremental  rotation.  The  final 
effect  is  to  rotate  the  outer  and  inner  squares  when  dial  1 
is  turned,  and  to  rotate  the  inner  square  relative  to  the 
outer  square  when  dial  2  is  turned. 

2.2.3  FGN  code 

In  the  description  of  the  Functional  Graph  Network 
language,  the  programs  have  been  described  in  graphical 
terms.  In  fact,  the  graph  structures  are  specified  to  the 
PS300  using  a  textual  program,  which  looks  like  an  ordinary 


programming  language.  Below  is  the  code  which  builds  the 
display  tree  and  functional  network  used  in  the  "Rotate 
Squares"  example. 


1.  square  :=  vector  list 

.5, .5  .5, -.5  -.5, -.5  -.5, .5  .5, .5; 

2.  double_squares  :  =  begin  structure 

3.  rot_out  :=  rotate  ^T; 

4.  instance  square; 

5.  scale  .4,. 4; 

6.  rot_in  :**  rotate  0; 

7.  instance  square; 

8.  end_structure; 

9.  rotate_outer  :=»  fsdzrotate; 

10.  rotate_inner  :=*  f:dzrotate; 

11.  connect  dials<l> : <l>rotate_outer ; 

12.  connect  dials<2> : <l>rotate_inner ; 

13.  connect  rotate_outer<l>:<l>double_square.rot_out; 

14.  connect  rotate_inner<l>:<l>double_square.rot_in; 

15.  display  double_squares ; 


The  program  begins  with  the  specification  of  the 
display  tree.  Line  1  defines  a  vector  list  named  "square", 
which  is  a  unit  square  centered  about  the  origin  of  the  X,Y 
plane  (the  Z  coordinates  default  to  0).  Line  2  through  line 
8  define  a  structure  named  "double_squares".  The  two 
transformation  nodes  "rot_out"  and  "rot_in"  are  defined  with 
in  lines  3  and  6  with  the  "rotate"  statement;  the  initial 
rotation  is  0  degrees.  The  unlabeled  transformation  node 
used  to  scale  down  the  smaller  square  is  defined  in  line  5. 
Lines  4  and  7  establish  the  outer  and  the  inner  instances  of 


a  square. 


The  functional  network  for  the  "Rotate  Squares"  example 


is  defined  in  lines  9  through  14.  First  the  nodes 
"rotate_outer"  and  "rotate_inner"  are  created  in  lines  9  and 
10.  The  node  "dials"  is  a  predefined  system  function  node. 
In  lines  11  through  14  the  connections  in  the  network  and  to 
the  display  tree  are  made. 

The  code  to  create  the  display  tree  and  functional 
network  is  downloaded  from  a  host  computer  to  the  PS300 
workstation  through  a  serial  line.  In  line  15  the  statement 
"display  double_squares"  causes  the  two  concentric  squares 
of  the  "Rotate  Squares"  example  to  appear  on  the  screen. 

The  ultimate  purpose  of  the  Graph  Design  Assistant  is 
to  produce  FGN  code  from  a  graphical  specification  as 
opposed  to  the  textual  program  specification  shown  in  the 
above  example.  With  this  goal  in  mind,  the  next  step  is  to 
examine  some  design  goals  for  the  GDA. 

2.3  Design  Goals  for  the  Graph  Design  Assistant 

The  purpose  of  the  GDA  is  to  allow  the  user  to  program 
the  PS300  without  having  to  learn  the  intricacies  of  its 
dataflow  language.  The  design  goals  to  accomplish  this 


The  GDA  allows  the  use  to  create  a  program  by  build  a 
graph.  The  graph  is  presented  to  the  user  visually  on  the 
computer  terminal.  The  user  enters  commands  by  pointing  to 
items  on  the  screen  with  a  mouse.  When  an  item  has  been 
"moused"  it  displays  a  menu  of  functions  that  can  be  applied 
to  the  item.  The  reason  for  the  emphasis  on  visual 
programming  is  to  free  the  user  from  having  to  know  and 
remember  a  specific  syntax  (as  is  required  when  defining  a 
functional  network  using  the  written  text  form  of  the  FGN 
language) . 

Design  goal  2;  Create  and  use  plans 

A  significant  problem  with  programming  the  PS300  using 
the  FGN  language  is  that  there  is  no  method  for  defining  a 
"macro".  If  a  functional  network  contains  several  identical 
sub-graphs,  the  user  has  to  write  code  to  define  each  one 
individually. 

The  notion  of  a  plan  is  similar  to  a  macro.  Once  a 
plan  has  been  defined,  it  can  be  instantiated  (or  called)  to 
produce  a  graph  structure.  A  plan  is  different  from  a 
macro,  however,  in  that  the  plan  is  more  flexible.  A  single 
plan  may  expand  to  different  structures  depending  on  the 


context. 


The  advantage  of  being  able  to  define  and  use  plans  is 


that  a  library  of  plans  can  be  created.  When  the  G DA  is 
used  in  the  robot  simulation  facility,  a  library  of  plans 
geared  toward  the  creation  of  robot  simulations  will  exist. 
This  amounts  to  creating  a  higher  level  language  which  frees 
the  user  from  the  underlying  details  of  the  FGN  language. 
Given  a  sufficiently  extensive  library  of  plans,  the  typical 
user  will  be  able  to  construct  robot  simulations  by 
selecting  plans  from  the  library. 

Design  goal  4:  Consistency  checking 

In  construction  a  functional  network  graph,  there  are 
many  opportunities  for  a  user  to  make  mistakes.  On  of  the 
goals  for  the  Graph  Design  Assistant  is  to  automatically 
detect  errors  during  the  construction  of  a  graph  and  inform 
the  user. 

There  are  different  types  of  consistency  checks  can 
make  on  a  functional  network.  For  example  tests  could  be 
made  for  the  following  conditions:  the  inputs  and  outputs  of 
each  node  need  to  be  connected,  output  connections  must  be 
made  to  input  connections  that  are  compatible  data  types, 
and  the  functional  network  should  be  a  "live"  network. 


Liveness  is  a  property  of  a  well  defined  behaved 
dataflow  programs  (Davis,  1984:3.2).  A  network  is  a  alive 
if  data  tokens  propagate  throughout  the  graph.  Data  tokens 
must  be  available  on  all  the  input  nodes  of  a  functional 
node  before  the  node  fires.  A  dead  network  has  nodes  which 
can  never  fire. 


2.4  User  Interaction  Scenario 


The  Graph  Design  Assistant  is  a  "highly  interactive" 
system.  The  following  scenerio  was  devised  in  an  attempt  to 
define  the  interactive  requirements  for  GDA. 

The  construction  of  FGN  programs  can  be  viewed  as  a 
part  of  a  design  process.  In  particular,  the  user  of  GDA  is 
designing  a  graph  which  is  a  representation  of  the 
functional  graph  network.  The  model  of  the  design  process 
used  in  GDA  is  "abstract  refinement"  (Mostow,  1985:45).  In 
the  abstract  refinement  model,  a  design  is  constructed  at  a 
series  of  levels  (as  in  Figure  2.5).  The  designer  begins  at 
the  top  level  with  a  few  abstract  components.  The  designer 
refines  components  at  lower  levels.  Each  lower  level 
corresponds  to  a  refined  design  for  a  higher  level 
component.  (In  conventional  software  engineering  this 
method  is  known  as  top  down  structured  design.)  Although 
this  method  sounds  simple,  there  can  be  difficulties  if  the 
components  are  not  completely  independent  of  each  other.  In 
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Figure  2.5  Scenario:  An  Example  Design  Hierarchy 


the  functional  graph  network,  there  are  many  interconnec¬ 
tions  between  components;  GDA  checks  the  user's  design  for 
mistakes. 

What  follows  is  a  description  of  a  typical  session 
using  GDA  to  design  a  Functional  Graph  Network.  The  purpose 
of  this  desciption  was  to  help  define  the  functional 
specifications  for  the  Graph  Design  Assistant. 

The  designer  in  this  scenario  designs  a  functional 
graph  network  to  animate  and  control  a  6  axes  robot  arm. 
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Figure  2.3  Scenario:  Level  1  Animate  Robot 


The  robot  arm  is  controlled  by  12  function  keys  on  the 
keyboard  of  the  PS300.  Each  axis  of  the  robot  is  controlled 
with  two  keys.  The  first  key  starts  and  stops  the  rotation 
about  an  axis,  while  the  second  key  changes  the  direction  of 
the  rotation. 


Scenario:  Design  of  level  1 


The  designer  constructs  a  graph  by  instantiating  nodes 
and  making  connections  between  nodes.  The  designer  can 
either  choose  predefined  nodes  from  a  library  or  create  new 


sub-graph  nodes.  Figure  2.6  shows  the  design  at  level  1. 

The  designer  has  instantiated  six  copies  of  the  plan 
"rotate-axis(x/y/z)",  and  one  copy  of  the  display  tree 
description  "robot-tree" .  In  addition,  the  designer  has 
created  a  sub-graph  node,  "toggle-keys",  which  must  be 
refined  later. 

The  "robot-tree"  node  is  a  description  of  a  display 
tree.  In  practice,  this  tree  would  be  defined  by  some  other 
development  tool.  The  tool  would  generate  the  actual  dis¬ 
play  tree,  which  is  downloaded  to  the  PS300,  as  well  as  a 
description  of  the  display  tree  for  use  in  the  GDA.  A 
display  tree  is  a  data  structure  that  describes  the  image  of 
the  robot.  It  consists  of  vector  lists  and  transformation 
nodes.  The  PS300  has  a  display  processor  which  repeatedly 
scans  the  display  tree,  applying  the  rotation,  translation, 
and  scaling  transformations  to  the  vectors  to  produce  the 
image  on  the  display  screen.  The  transformation  nodes  in 
the  tree  can  be  labeled  so  that  they  can  receive  input  from 
the  the  function  graph  network. 

The  display  tree  description  contains  knowledge  that 
GDA  must  have  to  build  a  functional  network  that  will 
interface  correctly  with  the  display  tree.  The  description 
contains  a  list  of  transformation  nodes  and  information 
about  constraints  on  the  nodes.  The  robot  arm  described  by 
"robot-tree"  (Figure  2.6)  has  six  joints.  "Robot- tree" 
contains  a  list  of  the  six  nodes  labeled  "al",  "a2", . . ."a6". 


The  description  also  contains  constraint  information  about 
each  node;  the  joints  are  limited  in  the  amount  they  can 
rotate  and  which  axis  (x,  y,  or  z)  they  can  rotate  about. 

The  "toggle-keys"  node  is  a  sub-graph  node.  The 
detailed  design  of  this  node  is  described  later.  (The  system 
automatically  puts  a  notice  on  the  agenda  that  design  of 
"toggle-keys"  must  be  refined.  The  designer  selects  the 
notice  from  the  agenda  when  he  decides  to  complete  the 
design.)  The  "toggle-keys"  sub-graph  allows  the  function 
keys  to  act  as  boolean  toggle  switches.  A  boolean  toggle 
switch  alternately  outputs  a  "true"  then  a  "false"  each  time 
the  switch  is  pressed. 

The  "axis-rotate(x/y/z)"  node  is  a  plan  that  generates 
an  network  which  causes  a  transformation  node  on  a  display 
node  to  rotate  about  the  x,  y,  or  z  axis.  The  inputs  to 
this  node  are  boolean  values.  If  the  "on"  input  is  true, 
then  the  node  outputs  rotational  transformations  until  the 
input  changes  to  false.  If  the  "clockwise"  input  is  true, 
the  rotation  is  clockwise,  otherwise  it  is  counter 
clockwise.  When  FGN  instantiates  this  plan,  it 
automatically  checks  the  description  of  the  "robot-tree"  to 
determine  which  axis  to  rotate,  and  what  rotation  limits  to 
build  into  the  network. 

In  the  final  step  of  the  design  of  level  1,  the 
designer  selects  the  "toggle-keys"  node  and  tells  GDA  to 
"zoom  in"  on  this  node.  The  window  displaying  the  current 


graph  clears  and  the  designer  begins  the  design  of  the  sub¬ 
graph  for  "toggle-keys". 


Scenario:  Refinement  of  level  2*s  "toggle-keys" 

The  design  process  at  level  2  of  the  hierarchy  is 
exactly  the  same  as  for  level  1.  The  designer  selects 
predefined  nodes  from  the  library,  or  creates  new  sub-graph 
nodes  (to  be  refined  later).  Figure  2.7  shows  the  final 
design  of  "toggle-keys".  The  12  identical  "toggle"  nodes 
could  have  easily  been  predefined  nodes  selected  from  a 
library,  however  for  the  purposes  of  this  example  the 
designer  created  them  as  sub-graph  nodes.  The  "fkeys"  and 
"f:croute"  nodes  are  primitives  of  the  FGN  language.  The 
"fkeys"  node  outputs  an  identifying  integer  each  time  a 
function  key  on  the  PS300's  keyboard  is  depressed.  The 
"f:croute"  function  node  has  two  inputs.  Input  1  selects 
which  output  the  data  from  input  2  is  directed  to.  In  this 
configuration,  whenever  function  key  6  is  depressed,  a  6  is 
sent  from  output  6  of  "ficroute".  This  in  turn  causes  the 
"toggle"  node  (connected  to  output  6  of  "ficroute")  to 
toggle  it's  output  from  true  to  false,  or  false  to  true. 

Next,  the  designer  selects  one  of  the  "toggle"  nodes  to 
refine  the  design  (since  all  12  of  the  toggle  nodes  are 
identical,  the  user  only  has  to  design  "toggle"  once). 


Figure  2.7  Scenario:  Level  2  "Toggle  Keys 


Scenario:  Refinement  of  level  3's  "toggle" 


Since  this  is  the  lowest  level  of  the  design,  the  user 
instantiates  primitive  FGN  function  nodes.  The  toggle 
function  is  shown  in  Figure  2.8.  The  "f: constant"  node 
works  by  triggering  whenever  it  receives  data  on  input  1. 
When  ever  "fsconstant"  triggers  it  outputs  the  constant 
value  on  input  2.  In  this  case  "frconstant"  outputs  a  true 
whenever  it  receives  data  on  input  1.  The  output  from 


"f:constant"  goes  to  the  "f:xorM  node.  This  performs  an 
"exclusive  or"  operation  on  the  input  1  (always  true)  and 
input  2  (the  last  output  value).  The  effect  is  that  the 
"f:xor"  node  outputs  a  data  token  that  is  the  compliment  of 
the  node's  previous  output. 


Figure  2.3  Scenario:  Level  3  "Toggle" 

The  above  scenario  describe  some  of  the  possible 
interactions  between  the  user  and  GDA.  Two  aspects  of  GDA, 
however,  were  not  brought  out  in  the  scenario.  One  is  the 
means  of  interaction  between  the  user  and  GDA.  GDA  uses 
graphic  to  display  the  state  of  the  design.  The  user  uses  a 
mouse  to  point  to  elements  on  the  display  to  carry  out  his 
commands.  For  example,  if  the  user  wants  to  connect  two 
nodes,  he  points  to  the  output  connection  of  the  source 
node,  clicks  the  mouse,  then  points  to  the  input  connection 
of  the  destination  node,  and  again  clicks  the  mouse  to 
complete  the  connection.  A  line  is  then  drawn  by  GDA  on  the 
screen  between  the  two  nodes.  The  second  aspect  of  GDA  not 


brought  out  in  the  scenario,  is  the  constant  consistency 
checking  that  occurs  during  the  design  process.  Suppose 
that  in  the  above  connection  example,  the  output  and  input 
nodes  had  been  incompatible.  Maybe  the  output  produced  an 
integer  token  while  the  input  only  accepted  real  tokens. 

GDA  would  detect  the  conflict  and  notify  the  user  of  the 
error.  In  addition,  it  would  post  a  notice  on  the  agenda  to 
insure  that  the  user  would  eventually  correct  the  error. 

The  above  scenerio  described  the  creation  of  a 
functional  network  using  the  Graph  Design  Assistant.  The 
scenario  served  as  a  functional  description  and  was  used  as 
a  basis  to  begin  the  design  presented  in  the  next  chapter. 


V'.-.I 


The  design  process  of  the  Graph  Design  Assistant  did 
not  follow  conventional  software  engineering  practice. 
Because  of  this,  the  first  section  of  this  chapter  examines 
and  justifies  the  development  strategy  used  in  this  thesis 
effort.  Next,  the  design  for  GDA's  system  architecture  is 
described.  And  finally  the  overall  software  design  is 
examined. 


3.1  Development  strates 


One  way  to  categorize  software  development  projects  is 
that  they  are  either  "design  problems"  or  they  are 
"implementation  problems"  (Sheil,  1983:20).  Because  the 
requirements  were  not  well  defined,  it  was  felt  that  the 
Graph  Design  Assistant  fell  into  the  category  of  a  "design 
problem". 

In  a  project  that  is  an  "implementation  problem",  the 
requirements  are  well  understood  from  the  start.  It  may  be 
that  the  project  is  a  redesign  of  and  existing  system  or 
design  of  a  system  which  is  similar  to  an  existing  system. 
This  is  not  to  say  that  the  "implementation  problems"  are 
trivial;  the  size  of  many  projects  can  make  them  very 
difficult.  There  is,  however,  a  well  developed  body  of 
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software  engineering  knowledge  that  can  aid  in  the 
development  of  large  "implementation  problems". 

The  "waterfall"  model  of  lifecycle  development  is 
useful  in  dealing  with  "implementation  problems".  The 
software  lifecycle  model  is  a  step  by  step  approach,  which 
begins  with  requirements  definition,  design,  code  and 
debugging,  testing,  and  finally  operations  and  maintenance 
(Boehm,  1976:72).  Although  there  may  be  some  feedback  in 
the  development  process,  steps  may  be  repeated,  the  general 
trend  is  to  finish  one  step  before  proceeding  to  the  next. 
It  is  very  important,  therefore,  in  a  lifecycle  development 
that  the  requirements  are  well  defined  before  proceeding  to 
the  development  phase. 

Unfortunately,  in  a  "design  problem"  type  project,  the 
requirements  are  often  difficult  to  define  until  the  system 
has  been  built  (Floyd,  1984:2;  Sheil,  1983:20).  The 
requirements  for  the  system  were  poorly  defined  at  the 
beginning  of  the  effort.  There  were  no  available  "dataflow 
programming  assistant"  systems  to  model  GDA  after.  In  an 
attempt  to  alleviate  the  problems  with  imprecise 
specifications,  two  related  strategies,  "prototyping" 
(Floyd,  1984)  and  "exploratory  programming"  (Sheil,  1983), 
were  used  in  the  development  of  the  Graph  Design  Assistant. 


The  definition  of  prototyping  in  relation  to  software 
development  is  a  problem.  The  literal  meaning  of 
prototype,  "first  of  a  type",  and  its  use  in  other 
engineering  disciplines  does  not  correspond  with  the  way  it 
is  used  in  software  engineering.  For  the  purposes  of  this 
effort,  a  prototype  is  an  "experimental  prototype"  primarily 
designed  to  enhance  the  specification  of  a  system  (Floyd, 
1984:9). 

It  should  be  mentioned  that  prototyping  is  not 
completely  incompatible  with  the  lifecycle  approach  to 
software  engineering.  First,  the  development  of  a  prototype 
can  be  viewed  as  the  first  step  (requirements  definition)  in 
the  normal  lifecycle.  Second,  the  process  of  developing  the 
prototype  may  undergo  the  phases  of  the  lifecycle,  although 
the  steps  might  not  be  rigidly  controlled. 

The  success  of  a  prototyping  strategy  depends  in  a 
large  part  upon  the  availability  of  appropriate  development 
tools.  Because  of  the  possibility  that  the  prototype  may 
serve  as  a  "throwaway"  learning  device,  it  is  important  that 
the  prototype  can  be  developed  at  a  relatively  low  cost 
(Floyd,  1984:  10).  For  this  reason,  "exploratory 
programming"  is  the  second  part  of  GDA's  development 
strategy. 


3.1.2  Exploratory  Programmiiv 


Exploratory  programming  has  been  defined  as  the 
"conscious  intertwining  of  system  design  and  implementation" 
using  advanced  programming  environments  (Sheil,  1983:19). 

The  second  strategy  in  the  development  of  the  Graph  Design 
Assistant  was  to  use  tools  developed  for  Artificial 
Intelligence  (AI)  research  and  applications.  Researchers  in 
AI  have  attempted  to  build  large  systems  in  order  to  solve 
poorly  understood  problems.  Usually  they  are  built  quickly 
with  small  programming  teams.  During  the  course  of 
development  the  programs  undergo  many  modifications  due  the 
fact  that  the  problems  are  so  difficult.  A  consequence  of 
the  challenges  of  AI  research  have  been  the  development  of 
powerful  "exploratory  programming  environments"  (Sheil, 
1983:22). 

Early  in  the  design  of  the  Graph  Design  Assistant  the 
decision  was  made  to  such  a  tool  developed  for  AI 
applications.  The  Knowledge  Engineering  Environment  or  KEE 
(Intellicorp,  1985c).  KEE  is  a  hybrid  development 
environment  that  combines  frame-based  knowledge 
representation,  object  oriented  programming,  and  rule-based 
reasoning  (Fikes,  1985:906;  Kunz,  1984:  41). 

The  version  of  KEE  which  was  available  ran  on  a 


Symbolics  3600  "lisp  machine"  (Symbolics,  1985a).  A  feature 
of  KEE  that  proved  extremely  useful  is  that  it  allows  easy 


access  to  the  underlying  Symbolics  development  environment. 
The  Symbolics  supports  Zetalisp  as  its  programming  language 
and  operating  system  (Symbolics,  1985b).  The  Zetalisp 
environment  provides  many  programming  tools  such  a  syntax 
sensitive  editor,  symbolic  debugger  (Symbolics,  1985c). 

Most  importantly  for  the  implementation  of  the  Graph  Design 
Assistant,  the  Zetalisp  environment  has  many  functions  for 
doing  graphic  and  windows  (Symbolics,  1985d: 73-126) ,  and 
building  mouse  and  menu  based  user  interfaces  (Symbolics, 
1985d:  207-255) 


Graph  Design  Assistant  Architecture 


The  decision  to  use  KEE  in  the  implementation  of  the 
Graph  Design  Assistant  had  a  large  influence  in  the  design 
of  the  system  architecture.  In  this  section,  the  system 
architecture  is  examined.  First,  the  hardware  configuration 
of  the  robot  simulation  facility  is  shown.  Then,  the 
software  architecture  of  the  GDA  is  described. 


3.2.1  Robot  Simulation  Facility  Hardware  Configuration 


The  hardware  used  in  the  present  configuration  of  the 
robot  simulation  facility  consists  of  a  Symbolics  3600 
computer,  a  VAX  11/780  computer,  and  an  Evans  and  Sutherland 
PS300  graphic  workstation. 
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Figure  3.1  Robot  Simulation  Facility  Hardware  Configuration 

Figure  3.1  shows  the  components  and  their  connections. 
At  the  present  time  a  serial  line  connects  the  Symbolics  to 
the  VAX  (an  Ethernet  connection  is  planned)  and  the  VAX  to 
the  PS 300. 

At  the  bottom  of  Figure  3.1,  the  relationship  between 
the  hardware  components  and  the  user  roles  (defined  in 
chapter  2)  are  shown.  The  Robot  Display  Designer  develops 
FGN  programs  on  the  Symbolics  using  the  Graph  Designer 
Assistant.  The  programs  are  downloaded  to  the  PS300  through 
the  VAX.  The  Robot  Control  Program  Developer  write  his 
control  programs  on  the  VAX.  The  Robot  Model  User  interacts 
with  a  model  through  the  PS300  workstation. 

A  crucial  component  of  the  robot  simulation  facility  is 


the  Evans  and  Sutherland  PS300  workstation.  This  decision 


to  uses  this  device  was  made  because  it  is  well  suited  for 
displaying  animated  robot  simulations.  The  PS300  is  capable 
of  displaying  three  dimensional  images.  The  images  can  be 
animated  in  real-time.  The  calculations  to  do  the 
rotations,  scalings  and  translations  used  in  the  animation 
of  the  image  are  made  with  special  purpose  hardware  residing 
in  the  PS300  (Evans  and  Sutherland  Computer  Corporation; 
1984a;  Foley,  1982:418-421) 

The  VAX  11/780  acts  as  a  host  computer  for  the  PS300 
workstation.  The  PS300  can  emulate  a  normal  terminal  as 
well  as  performing  its  graphic  functions.  Because  the  PS300 
performs  its  graphic  functions  in  local  hardware,  it  makes 
few  demands  on  the  VAX  (it  is  likely  the  the  11/780  will  be 
replaced  with  a  smaller  model  of  the  VAX).  The  VAX  can 
se'-e,  however,  in  the  development  and  execution  of  planning 
and  control  program  which  will  interact  with  simulations 
running  on  the  PS300. 

The  decision  to  include  the  Symbolics  3600  in  the  robot 
simulation  facility  was  based  on  the  availability  of  the 
powerful,  AI  development  tools  available  within  the  Zetalisp 
environment.  Since  this  first  implementation  of  the  Graph 
Design  Assistant  is  a  prototype,  a  decision  might  be  made  to 
implement  future  versions  of  GDA  on  the  VAX  host  computer. 


The  organization  of  the  GDA  was  strongly  influenced  by 
the  choice  to  implement  the  system  with  KEE.  In  addition, 
the  method  for  describing  the  system  was  affected  by  KEE. 

It  is  difficult  to  describe  the  Graph  Design  Assistant 
using  documentation  techniques  such  as  a  data  dictionaries 
and  structure  charts.  A  system  implemented  in  a 
conventional  programming  language  can  be  defined  by  the 
structure  of  the  system’s  data  and  the  procedural  code  that 
operates  on  the  data.  Normally  the  program  is  conceived  as 
a  hierarchy  of  procedures  or  modules,  and  the  software 
architecture  can  be  explained  in  terms  of  that  hierarchy 
(structure  charts  for  example). 

Unfortunately,  a  system  implemented  in  KEE  is  difficult 
to  describe  using  standard  software  engineering  graphical 
aids.  The  primary  component  of  a  KEE  implemented  system  is 
a  "knowledge-base".  KEE's  knowledge-bases  combine  both  data 
and  procedures  in  a  single  unit,  which  makes  it  difficult  to 
describe  the  system  with  data  dictionaries  and  structure 
charts. 

The  approach  that  has  been  taken  to  describe  the  Graph 
Design  Assistant  is  to  first  describe  the  in  general, 
knowledge-bases  and  their  and  their  relationships  (in  this 
chapter).  Then  the  objects  which  comprise  the  knowledge¬ 
bases  are  described  in  detail  (in  the  next  chapter). 
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Figure  3.2  Graph  Design  Assistant  Architecture 


GDA  knowledge-bases.  Figure  3.2  shows  the  knowledge¬ 
bases  of  the  Graph  Design  Assistant  and  indicates  the 
relationships  between  them.  In  addition  to  the  knowledge¬ 
bases,  the  processes  which  comprise  the  user  interface  are 


The  knowledge-bases  are  depicted  in  Figure  3.2  as  boxes 
with  rounded  corners.  They  are  GDA-SYSTEM,  FGN-GRAMMAR,  and 
USER-GRAPHS.  A  knowledge-base  contains  either  information 
which  describes  the  attributes  of  objects,  or  the  objects 
themselves.  The  knowledge  representation  scheme  used  by  KEE 
represents  objects  as  a  taxonomy  of  "frames"  (Fikes,  1985: 
907). 

Frames  have  any  number  of  slots.  The  slots  may  contain 
declarative  or  procedural  knowledge.  The  frames  are 
arranged  in  a  tree  structure  of  object  classes.  A  class  is 
the  description  of  an  object  as  opposed  to  the  actual  object 
(members).  A  frame  inherits  traits  (slots)  from  its  parent 
classes.  The  top  of  the  hierarchical  is  the  most  general 
description  of  a  class  of  objects.  Lower  level  frames 
refine  the  description  of  object,  while  the  "leaves"  of  the 
tree  structure  are  memb  rs  of  the  class. 

For  example  in  Figure  3.2  the  knowledge-base  GDA-SYSTEM 
contains  the  most  general  description  of  objects.  The  solid 
line  from  GDA-SYSTEM  to  FGN-GRAMMAR  denotes  that  there  are 
frames  in  FGN-GRAMMAR  with  are  child  classes  of  frames  in 
GDA-SYSTEM.  In  other  words,  GDA-SYSTEM  describes  "generic" 
graph  elements,  while  FGN-GRAMMAR  describes  graph  elements 
that  are  specific  to  the  Functional  Graph  Network  language 
of  the  PS300.  The  dashed  line  from  GDA-SYSTEM  to  FGN- 
GRAMMAR,  indicates  that  some  of  the  objects  are  members  of  a 
parent  class  defined  in  GDA-SYSTEM. 


The  FGN-PLANS  knowledge-base  contains  the  members  of 
the  plan  library.  Plans  are  structures  similar  to  macros 
which  can  be  expanded  into  complex  structures  to  use  in  the 
building  of  graphs. 

The  USER-GRAPHS  knowledge  base  contains  only  members  of 
the  classes  defined  in  the  other  knowledge-bases.  This 
knowledge-base  contains  the  functional  network  graphs  that 
the  user  is  currently  creating  and  editing. 

The  elliptical  shapes  in  Figure  3.2  indicate  "window 
processes".  Window  processes  are  attached  to  user 
interaction  windows  (indicated  a  rectangles).  Windows  are 
displayed  on  the  screen  of  the  Symbolics  3600.  The  window 
processes  control  the  interaction  with  the  user  through  the 
mouse  or  keyboard  on  the  Symbolics  3600. 

The  process  labeled  KEE-INTERFACE  was  not  as  part  of 
the  Graph  Design  Assistant  development,  but  is  a  built  part 
of  the  KEE  system.  It  is  shown  in  Figure  3.2  to  indicate 
that  the  knowledge-bases  can  be  modified  directly  from  KEE. 

The  process  labeled  GDA-INTERFACE  was,  on  the  other 
hand,  constructed  during  the  development  of  GDA.  In  a  sense 
this  part  was  developed  outside  of  the  KEE  environment 
because  certain  graphic  functions  were  needed  which  were  not 
available  within  KEE.  The  GDA-INTERFACE  controls  the 
creation  and  editing  of  graphs  within  the  USER-GRAPHS 
knowledge-base.  The  user  the  mouse  on  the  graph  window  to 
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call  up  menus  and  execute  commands  which  update  the  USER- 


GRAPHS  knowledge-base. 


The  lines  between  the  three  knowledge-bases  in  Figure 


3.2  are  indications  of  relationships  between  frames  within 


the  respective  knowledge-bases.  The  solid  line  indicates  a 


"sub-class"  relationship  and  a  dashed  line  indicates  a 
"member"  relationship.  A  particular  object  is  described  by 


a  hierarchy  of  classes;  the  classes  are  most  general  at  the 


top  of  the  tree,  and  become  more  specific  towards  the  bottom 


of  the  tree.  At  the  very  bottom  of  a  tree,  the  object 


itself  is  a  member  of  a  class. 


Figure  3.3  is  a  closer  look  at  the  relationships 


between  the  three  knowledge  bases  in  the  Graph  Design 


Assistant.  It  shows,  for  illustration  purposes,  a  few 


example  frames  within  each  of  the  knowledge  bases. 


The  object  labeled  DZR_12  within  the  USER-GRAPHS 
knowledge  base  in  an  part  of  a  functional  network  graph.  It 


is  described  by  the  class  DZROTATE,  which  is  in  turn  a  sub¬ 


class  of  PRIMITIVE,  which  is  a  sub-class  of  GRAPH-ELEMENT. 


The  class  DZROTATE  is  specific  to  the  PS300's  FGN  language, 


hence  it  resides  in  the  FGN-GRAMMAR.  The  class  PRIMITIVE, 


on  the  other  hand,  describes  an  element  that  could  be  in 


many  different  dataflow  grammars.  In  other  words,  it  is  a 
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Figure  3.3  Graph  Design  Assistant  Knowledge  Bases 


more  general  class.  The  class  GRAPH-ELEMENT  is  even  more 
general;  it  consists  of  all  the  elements  which  go  to  make  up 
a  graph  (including  primitives). 

The  DZROTATE  frame  shown  in  Figure  3.3,  in  addition  to 
being  a  class  description,  is  also  a  member  of  the  GDA’s 
library.  It's  a  sub-class  of  FGN-PRIMITIVE  (a  FGN  specific 
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class),  which  is  a  sub-class  of  LIBRARY  (a  general  class 
applicable  to  any  dataflow  grammar). 

In  this  chapter  the  strategy  to  develop  a  prototype 
using  an  "exploratory  programming"  environment  was 
described.  The  high-level  design  of  the  Graph  Design 
Assistant  was  discussed.  In  the  next  chapter,  the  design 
and  implementation  details  of  GDA  are  presented. 


IV.  Detailed  Design  and  Implementation 


The  majority  of  the  Graph  Design  Assistant  system  was 
implemented  using  the  Knowledge  Engineering  Environment 
(KEE)  (Intellicorp,  1985).  A  system  is  created  with  KEE  by 
defining  knowledge  bases.  Knowledge  bases  contain  both  the 
procedural  and  declarative  knowledge  about  the  system. 

The  chapter  begins  with  a  description  of  the 
representation  of  dataflow  graphs.  Next,  some  of  the 
knowledge  bases  the  Graph  Design  Assistant  are  described. 
Finally,  the  detail  design  and  implementation  of  GDA's  user 
interface  are  presented. 


4.1  Representation  of  Dataflow  Graphs 


In  the  previous  chapter,  the  ’’abstract  refinement" 
model  of  the  design  process  was  discussed.  Because  of  the 
design  process,  the  user  view  of  the  dataflow  graph  is  a 
hierarchical  tree  structure.  At  the  top  of  the  tree  are  are 
high  level  representations  of  graphs,  while  at  the  bottom  of 
the  tree  are  primitive  functional  nodes. 

Figure  4.1  shows  the  different  design  levels  of  a 
dataflow  graph  as  conceived  by  a  user.  The  design  of  the 
overall  graph  G1  is  shown  at  level  1.  It  consists  of  two 
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Figure  4.1  User  s  Design  Hierarchy 


sub-graphs,  Gl.l  and  G1.2.  The  the  output  from  graph  Gl.l 
is  directed  to  the  input  of  G1.2. 

Level  2  of  Figure  4.1  shows  further  refinement  of  the 
design.  The  graph  Gl.l  consists  of  an  input  connector,  a 
sub-graph  Gl.1.1,  a  primitive  P3,  and  an  output  connector. 
The  graph  G1.2,  also  at  level  2,  has  an  input  connection, 
and  two  primitives,  P4  and  P5.  Level  3  of  Figure  4.1  is  a 
refinement  of  the  graph  Gl.1.1.  It  contains  two  primitives 
PI  and  P2. 

The  functional  network  graph  which  is  produced  by  the 
hierarchical  design  of  Figure  4.1  is  actually  a  "flat" 


structure.  The  hierarchical  structure  is  due  to  the  user's 
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Figure  4.2  "Flat"  Functional  Network 

design  abstractions  in  the  form  of  sub-graphs.  Figure  4.2 
shows  the  dataflow  graph  which  consists  of  the  primitives 
PI,  P2,  P3,  P4  and  P5.  The  light  "dotted"  square  outlines 
show  the  sub-graphs  that  produced  each  part  of  the  network. 

In  the  designing  GDA,  a  representation  for  dataflow 
graphs  was  devised  that  captured  the  hierarchical  design 
information,  and  yet  was  easily  transformed  into  a  flat 
functional  network. 

A  simple  two  level  design  hierarchy  was  used  to 
explain  the  representation  of  functional  networks.  Figure 
4.3  shows  the  user’s  view  of  the  simple  functional  network. 
The  rectangles  represent  the  image  the  user  would  see  in  the 
Graph  Window.  The  top  level  graph  G1  (the  label  runs  along 
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Figure  4.3  A  User  s  View  of  a  Dataflow  Graph 

the  top  of  the  window)  has  a  primitive  node  PI  and  a  sub¬ 
graph  node  G3. 

G3  is  a  graph.  The  window  labeled  G3_G1  (G3's  full 
name)  shows  that  G3  has  an  input  connection,  II,  which  is 
connected  to  a  primitive  P3. 

The  data  structure  used  to  represent  the  simple  design 
hierarchy  is  shown  in  Figure  4.4.  There  are  three  different 
types  of  elements  in  Figure  4.4.  The  rectangles  are  nodes 
of  the  functional  network  (primitive  names  begin  with  a  "P" 
and  graph  names  begin  with  a  "G").  The  ellipse  shapes  are 
connectors  (input  connector  names  begin  with  a  "I”  and 
output  connectors  names  begin  with  an  "0").  The  "lozenge" 
shapes  are  arcs  (arc  names  begin  with  an  "A"). 
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Figure  4.4  Data  Structure  for  the  Dataflow  Graph 

The  three  types  of  elements  in  Figure  4.4  are  connected 
with  directed  lines  which  represent  different  relationships 
between  the  elements.  Most  of  the  relationships  in  Figure 
4.4  are  "sub-element"  relationships.  For  example,  the  graph 
G3_G1  is  the  SUB-GRAPH  of  Gl.  The  exceptions  to  the 
sub-element  relationships  occur  in  conjunction  with  the 
arcs.  Arc  elements  use  a  FROM-CONNECTOR  and  a  TO-CONNECTOR 
relationship  to  show  were  the  arc  begins  and  ends. 

The  in  the  implementation  of  GDA,  a  frame-based 
knowledge  representation  tool  (KEE)  was  used  to  represent 


dataflow  graphs.  The  different  types  of  elements  (nodes, 
arcs,  and  connectors)  are  represented  with  units.  (A  unit 
is  a  frame  in  KEE).  Units  have  slots  which  can  contain 
pointers  to  other  units.  The  relationships  shown  in  Figure 
4.4  were  represented  with  slots.  The  P1_G1  primitive  unit, 
for  example,  has  a  slot  named  SUB-OUTPUT  that  contains  a 
pointer  to  01_P1_G1. 

The  names  used  for  elements  Figure  4.4  are  longer  than 
the  names  used  by  the  user  (Figure  4.3).  It  was  necessary 
to  design  a  naming  convention  to  insure  that  each  unit  in 
the  KEE  knowledge  base  has  a  unique  name.  The  first  part  of 
each  name  consists  of  the  name  used  by  the  user,  followed  by 
the  path  (following  the  sub-element  relations)  to  the  top  of 
the  tree.  The  primitive  P3  (Figure  4.3)  has  a  long  name  of 
P3_G3_G1  because  P3  is  a  SUB-PRIMITIVE  of  G3 ,  which  is  a 
SUB-GRAPH  of  Gl. 

The  dataflow  graph  shown  in  Figure  4.4  is  part  of  the 
USER -GRAPHS  knowledge-base.  The  classes,  which  contain  the 
definitions  for  the  elements  in  the  dataflow  graph,  are 
contained  in  the  GDA-SYSTEM  and  FGN-GRAMMAR  knowledge  bases. 
The  next  section  discusses  the  knowledge  bases  which 
comprise  the  Graph  Design  Assistant. 


As  was  previously  mentioned,  the  Graph  Design  Assistant 
was  implemented  by  building  KEE  knowledge  bases.  The  two 
major  knowledge  bases  which  define  the  Graph  Design 
Assistant  are  the  GDA-SYSTEM  and  the  FGN-GRAMMAR  knowledge 
bases  (see  Figure  3.2  and  Figure  3.3).  The  other  knowledge 
base,  USER -GRAPHS,  is  not  part  of  GDA's  definition,  but 
contains  the  dataflow  graphs  the  user  is  currently  editing. 

This  sections  examines  GDA-SYSTEM  and  FGN-GRAMMAR  in 
more  detail.  Specifically,  some  of  the  individual  units 
within  each  knowledge  base  are  described.  The  purpose  of 
this  section  is  to  show  some  of  the  techniques  used  in  the 
implementation  of  GDA.  It  is  not  intended  to  exhaustively 
describe  all  of  the  units  and  all  of  their  slots.  A  listing 
of  the  complete  contents  of  the  knowledge  bases  can  be  found 
in  Appendix  A. 

The  GDA-SYSTEM  knowledge  base  contains  the  "generic" 
knowledge  about  dataflow  graphs.  The  FGN-GRAMMAR  knowledge 
base,  on  the  other  hand,  contains  knowledge  about  a  specific 
dataflow  language,  the  Functional  Graph  Network  (FGN) 
language. 

One  of  the  important  classes  of  objects  defined  in  GDA- 
SYSTEM  is  a  "graph  element".  The  graph  elements  are  objects 
which  are  used  to  construct  the  representation  of  a  dataflow 
graph  that  resides  in  the  USER-GRAPHS  knowledge  base. 
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Figure  4.5  Graph  Element  Class  Hierarchy 


The  graph  elements  are  defined  with  a  hierarchy  of 
classes.  Figure  4.5  shows  the  classes  used  to  define  the 
graph  elements.  Each  class  shown  in  the  tree  is  a  separate 
unit  (or  frame)  within  the  GDA-SYSTEM  knowledge  base.  The 
top  unit  of  the  hierarchy  is  GRAPH-ELEMENT.  The  lines  in 
Figure  4.5  indicate  sub-class  relationships.  Therefore, 
JUNCTION,  NODE,  and  are  sub-classes  of  GRAPH-ELEMENT. 

The  purpose  of  the  hierarchy  is  the  common  properties 
can  be  "inherited"  rather  than  defined  separately  within 
each  unit  (Intellicorp ,  1985d: 5. 1-5. 7)  .  An  inherited 
property  can  be  overridden  by  defining  that  property  at  a 
lower  level.  In  other  words,  the  inherited  property  is  a 
default,  but  may  be  replaced  if  necessary. 

The  properties  of  GRAPH-ELEMENT  are  the  most  general 
type  and  defined  at  that  level.  At  lower  levels  in  the 


hierarchy  (to  the  right  in  Figure  4.5)  the  properties  are 
more  specific  to  the  particular  type  of  element.  For 
example,  all  of  the  elements  of  a  graph  have  a  FIRSTNAME; 
therefore,  that  property  is  defined  in  the  GRAPH-ELEMENT 
unit  and  inherited  by  all  the  other  sub-classes.  The  NODE 
class  contains  a  SUB-INPUT  property  which  is  common  to  all 
of  it's  sub-classes  (PRIMITIVE  and  GRAPH),  but  is  not 
relevant  the  the  ARC  or  JUNCTION  classes. 

The  properties  of  a  class  are  represented  with  "slots". 
A  slot  can  contain  data  values,  "methods"  (a  procedure  or 
function),  "active  values"  (a  combination  of  a  data  value 
and  a  procedure)  (Intellicorp,  1985d:ll. 1-11. 7, 12. 1-12-8). 

In  order  understand  the  complete  definition  of  graph 
element  objects,  it  is  necessary  to  examine  the  units  and 
slots  of  the  classes,  as  well  as  the  class  hierarchy.  What 
follows  is  a  description  of  some  of  the  units  and  their 
slots  in  the  class  hierarchy  shown  in  Figure  4.5. 

GRAPH-ELEMENT  unit.  The  GRAPH-ELEMENT  is  the  most 
"generic"  class  description  of  the  elements  which  comprise  a 
dataflow  graph.  All  of  the  graph  elements  are  described  by 
sub-classes  of  the  GRAPH-ELEMENT  unit. 

One  of  the  data  slots  is  FIRSTNAME.  This  is  used  with 
a  method  slot  NAME-ELEMENT.  An  element  is  named  by  sending 
a  NAME-ELEMENT  message  to  that  element.  The  complete  name 
for  the  element  is  created  by  appending  the  FIRSTNAME  to  the 
name  of  the  element's  SUPER-ELEMENT. 


All  elements  have  a  method  slot  named  DRAW.  If  an 
element  receives  a  DRAW  message,  that  method  knows  how  to 
draw  a  graphic  representation  of  itself  in  a  window.  All 
elements  inherit  the  DRAW  slot,  however,  the  value  of  the 
slot  is  overridden  at  the  lower  levels  because  the  different 
types  of  elements  have  have  different  graphic  representa¬ 
tions.  The  immediate  sub-classes  to  GRAPH-ELEMENT, 

JUNCTION,  NODE,  and  ARC,  all  display  themselves  differently. 

Some  of  the  methods  defined  in  GRAPH-ELEMENT  have  to  do 
with  the  construction  and  modification  of  the  dataflow  graph 
representation.  INSTANTIATE  is  a  method  slot  in  GRAPH- 
ELEMENT.  When  a  class  receives  an  INSTANTIATE  messag°,  it 
creates  an  instance  of  that  class.  That  instance  is  the 
graph  element  which  becomes  part  of  the  dataflow  graph. 
DELETE  is  a  method  slot  in  GRAPH -ELEMENT.  When  an  element 
receives  a  DELETE  message  it  deletes  all  of  its  sub-elements 
(by  sending  them  DELETE  messages),  removes  pointers  to 
itself  from  its  super-element,  and  deletes  itself  from  the 
USER-GRAPHS  knowledge  base. 

JUNCTION  unit.  The  JUNCTION  class  describes  objects 
which  serve  as  the  connection  points  within  dataflow  graphs. 
The  DELETE  slot  in  JUNCTION  illustrates  a  variation  of  the 
normal  inheritance  mechanism.  Normally  when  a  slot  value  is 
defined,  its  new  value  simply  overrides  inherited  values. 

The  DELETE  method  which  was  inherited  from  GRAPH-ELEMENT  was 
applicable  to  JUNCTION  objects,  however  it  needed 


modification  to  work  correctly.  KEE  allows  the  definition 
of  "before"  and  "after"  methods  (Intellicorp,  1985:11.7- 
11.8).  In  definition  of  JUNCTION’S  DELETE  slot,  a  "before" 
method  was  added  to  delete  IN-ARC  and  OUT-ARC  pointers. 

This  section  of  code  is  executed  before  the  method  inherited 
from  GRAPH-ELEMENT.  The  "before"  and  "after"  methods  allows 
the  modifications  of  procedures  as  they  are  inherited  from 
sub-class  to  sub-class. 

4.3  Graph-Window  and  GDA-Interf ace 

The  principle  means  of  the  interfacing  GDA  with  the 
user  is  through  a  "graph-window"  and  its  associated 
"GDA-interface"  process  (Figure  3.2).  This  section 
describes  some  of  the  implementation  details  for  the  graph- 
window  and  the  GDA-interface.  The  descriptions  are  not 
meant  to  be  exhaustive  (the  source  code  is  found  in  Appendix 
B). 

The  graph-window  appears  as  rectangular  area  on  the 
screen  of  the  Symbolics  3600.  When  a  graph-window  is 
created  by  the  user,  a  GDA-interface  process  is  started. 

The  user  interacts  with  the  graph-window  by  selecting  menu 
items  with  the  mouse.  The  GDA-interface  process  receives 
the  menu  selections  and  executes  the  user's  commands. 


The  graph-window  and  GDA-interface  were  implemented 
outside  of  the  KEE  environment.  This  is  possible  because 


KEE  allows  complete  access  to  the  underlying  Symbolic's 
Zetalisp  programming  environment.  The  reason  that  the 
decision  was  made  to  implement  the  graph-window  outside  of 
KEE,  is  that  the  windows  used  by  KEE  did  not  support  the 
properties  that  were  needed  for  the  interface. 

Graph-window  interface  behavior.  The  graph-window 
interface  was  design  to  display  a  dataflow  graphs.  The  user 
makes  enters  commands  to  modify  graph  elements  by  pointing 
to  the  element  and  clicking  a  mouse  button.  There  are 
actually  two  active  buttons  for  the  graph-window  interface. 
The  left  button  always  executes  a  default  command  for  the 
object,  while  the  right  button  brings  up  a  "pop-up"  menu  of 
other  commands  applicable  to  the  object. 

Along  the  top  of  the  graph-window,  run  a  row  of  menu 
items  that  the  user  can  select.  These  invoke  commands  which 
are  applicable  to  objects  that  are  not  visible  in  the  window 
or  commands  which  apply  to  the  window  itself. 

The  Graph-window- f lavor .  The  windows  facility  in  the 
Symbolics  Zetalisp  environment  is  implemented  using 
Zetalisp' s  "Flavors"  system  (Symbolics  1985d:  207-255). 
Flavors  is  an  object  oriented  programming  system  where  first 
the  flavor,  of  an  object  is  defined,  then  the  object  is 
instantiated.  Objects  are  sent  messages  with  cause  the 
execution  of  "methods". 

The  graph-window  was  created  by  first  defining  a  flavor 
of  window  called  "graph-window-flavor".  Several  predefined 


Zetalisp  flavors  as  well  as  an  existing  KEE  window  flavor 
w  "mixed"  to  produce  the  graph-window-flavor.  The 
resulting  graph-window-flavor  had  all  of  the  properties 
(methods  and  variables)  of  the  Zetalisp  and  KEE  windows. 

In  addition,  the  graph-window-flavor  was  customized  further 
by  defining  new  methods. 


V.  Results ,  Conclusions,  and  Recommendations 


5.1  Results 


This  thesis  effort  resulted  in  the  design  and 
development  of  a  prototype  programming  tool  for  the 
development  of  dataflow  programs.  The  version  of  the  Graph 
Design  Assistant  should  serve  as  the  basis  for  further 
development  of  GDA.  In  addition,  GDA  can  serve  as  a  model 
for  similar  "visual  programming"  tools  applied  to  different 
programming  problems. 

Two  specific  results  were  the  design  of  a  represen¬ 
tation  for  dataflow  graphs  and  the  development  of  an  user 
interface  that  can  create  and  edit  dataflow  graphs. 

Not  all  of  the  original  goals  of  the  effort  were  met. 
The  intention  was  to  build  a  prototype  that  contained  all  of 
the  components  of  the  complete  GDA  system  (even  if  some  of 
the  parts  were  not  completely  developed).  The  actual 
implementation,  however,  did  not  contain  all  of  the  features 
envisioned  in  the  original  design.  There  is  only 
rudimentary  error  checking  of  the  dataflow  graphs,  and  the 
implementation  of  the  "plan"  creation  and  editing  capability 
was  not  completed. 


61 


o.2  Conclusions 


The  ''programmer '  s  assistant"  and  the  "visual 
programming"  approach  taken  by  GDA  appears  to  be  a  feasible 
way  to  create  dataflow  program.  Although,  the  prototype  did 
not  implement  all  of  the  features  necessary  for  a  robust 
programming  tool,  there  did  not  appear  to  be  any 
insurmountable  difficulties  in  building  a  complete  system. 

The  strategy  used  to  develop  GDA  was  an  important 
factor  in  making  it  possible  to  implement  the  system  in  a 
short  time.  GDA  was  developed  with  a  commercially  available 
"knowledge  engineering  tool"  (KEE).  During  the  short 
development  time  (approximately  3  man-months)  a  working 
prototype  was  developed.  In  the  judgment  of  the  author,  had 
the  development  effort  been  attempted  with  a  less  powerful 
programming  environment,  much  less  progress  would  have  been 
possible. 

5.3  Recommendations 


Continued  development  of  the  Graph  Design  Assistant. 
There  are  several  problems  that  were  not  adequately 
addressed  in  the  present  implementation  of  GDA.  The  repre¬ 
sentation  of  "plans"  needs  to  be  investigated.  This  is  the 
means  of  storing  domain  knowledge  in  GDA.  Plans  are 
selected  from  the  a  library  by  the  user  and  are  instantiated 
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to  form  parts  of  graphs.  The  representation  of  plans  should 
allow  for  the  encoding  of  knowledge  that  affects  how  the 
plan  expands.  For  example,  a  plan  that  controls  a  joint  on 
a  robot  should  be  able  to  build  a  network  that  incorporates 
constraints  that  apply  to  the  joint.  The  joint  may  be 
limited  in  the  speed  and  the  angles  it  can  rotate.  The 
functional  network  that  controls  the  joint  can  have  those 
limits  "built  in"  by  the  plan  when  it  is  instantiated. 

Evaluation  of  the  Graph  Design  Assistant.  At  some 
point,  an  effort  to  evaluate  the  effectiveness  of  GDA  should 
be  made.  This  could  be  done  by  comparing  the  experience  of 
users  who  learn  to  program  the  PS300  directly  by  writing 
text  FGN  programs  with  the  experience  of  users  who  learn  to 
program  the  PS300  using  the  GDA  system. 

Other  dataflow  "grammars".  The  present  implementation 
of  the  Graph  Design  Assistant  contains  representations  for 
one  particular  type  of  dataflow  graph.  It  was  design 
specifically  for  the  grammar  of  a  special-purpose  Functional 
Graph  Network  (FGN)  language  used  to  program  the  Evans  and 
Sutherland  PS300.  GDA  was  designed,  however,  so  that  the 
FGN  grammar  could  be  replaced  descriptions  of  other  dataflow 
languages. 

One  possibility  for  another  dataflow  grammar  which 
could  be  used  in  GDA  is  one  that  describes  the  robot 
simulation  facility.  In  the  chapter  2,  the  requirements  for 
the  robot  simulation  facility  were  specified  with  a  dataflow 
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diagram  (Figure  2.1).  It  should  be  possible  to  define  the 
process  (nodes  of  the  dataflow  diagram)  and  the  data  which 
passes  between  the  process  as  elements  of  the  grammar.  The 
objective  would  be  to  allow  the  user  to  dynamically 
configure  the  robot  simulations  using  by  editing  graphs  with 
GDA. 

An  even  more  general  dataflow  grammar  could  be  design 
to  configure  "real-time"  systems.  Dataflow  models  have  been 
proposed  as  a  method  of  specifying  real-time  systems 
(Allworth,  1981:13-24).  It  would  be  interesting  to  see  if 
the  capabilities  of  GDA  could  be  enhanced  to  allow  a  user  to 
build  real-time  systems  by  editing  dataflow  graphs. 


The  section  contains  listings  of  the  KEE  knowledge 
bases  which  define  the  Graph  Design  Assistant.  Each 
knowledge  base  listing  begins  with  the  name  of  the  knowledge 
base  followed  a  list  of  the  knowledge  base's  contents.  The 
knowledge  base  contains  units.  Each  unit  and  it's  slots  are 


Knowledge  Base;  SDA-SYSTEM 


Contents: 

ADD-ONLY-INPUTS 

ADD-ONLY-OUTPUTS 

ARC 

CONNECTOR 

CREATE-6RAPH-WINDGW 
CREATE-TREE-NINDQW 
DATA-TOKEN-TYPE 
SDA-ACT I VEVALUES 
6DA-C0HNANDS 

GDA-SYSTEM-UPDATE-COHNANDS 
6ET-L1 BRARY-MEMBERS-MENU 
GRAMMAR 
GRAPH 

GRAPH-ELEMENT 
IMAGE.  PANELM443 
IMAGES 

IN-CONNECTOR 

IN-PIN 

10-PIN 

JUNCTION 

LIBRARY 

METHOD.  ACTUAT0RM474 
METHOD.  ACTUATOR^1? 

METHOD. ACTUATORB0577 
NODE 

OUT-CONNECTOR 

OUT-PIN 

PLAN 

PLAN-LIBRARY 

PRIMITIVE 

PRIMITIVE-LIBRARY 

UPDATE-SUB-ELEMENT-POINTER 


Unit;  ADD-ONLY-INPUTS 
Members:  NIL 
Subclasses;  NIL 

Own  slot:  AVPUT 
Valued  ass:  NIL 

Values:  (LAMBDA  (SELF  SLOT  NEWVALUE  OLDVALUE  UNIT  SLOTIYPE) 
(IF  (BET. VALUE  UNIT  ’ INPUT-P)  NEWVALUE  OLDVALUE)) 


Unit:  ADD-ONLY-OUTPUTS 
Members:  NIL 
Subclasses;  NIL 


Unit:  ARC 

• 

Members;  NIL 

Subclasses:  NIL 

Jv 

w.v 

1  V  *  . 

Member  slot:  DEFAULT-NAME-PREFIX 

Valuedass:  NIL 
Values:  (A) 

Member  slot!  DELETE 
Valueclass:  NIL 

Values:  ((BEFORE  (LET*  ( (TO-JUNCTION  (SET. VALUE  SELF  ’ TO-JUNCTION)) 
(F RON -JUNCTION  (BET. VALUE  SELF  ’FRON-J UNCTION) ) » 
(REMOVE. VALUE  FROM-JUNCT ION  ’OUT-ARC  SELF) 

(REMOVE. VALUE  TO-JUNCTION  'IN-ARC  SELF)!! 


Member  slot:  DRAM 
Valueclass:  NIL 
Values:  (LAMBDA  (SELF  WINDOW) 

(SEND  WINDOW  : DRAW-ARC  SELF)) 
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Member  slot:  FROM-JUNCTION 
Valuedass:  (JUNCTION.) 

Values;  NIL 

Member  slot:  PARENT-SUB-POINTER-SLOT 
Valued  ass:  NIL 
Values:  (SUB-ARC) 

Member  slot:  PATH 
Valued  ass:  NIL 
Values:  NIL 

Member  slot:  TO-JUNCTIOH 
Valuedass:  (JUNCTION) 

Values:  NIL 


Unit:  CONNECTOR 

Members!  NIL 

Subclasses:  (*Umt  t OUT-CONNECTOR  GliA-SYSTEH)  »Unit  (IN-CCNNECTOR  GDA-SYS1EM!) 

Member  slot:  CONNECT-POINT-OFFSET 
Valuedass:  NIL 
Values:  NIL 

Member  slot:  ORAN 
Valuedass:  NIL 
Values:  (LAMBDA  (SELF  WINDOW* 

(SEND  I4IN00W  : DRAW-CONNECTOR  SELF)  ■ 

Member  slot:  IN-ARC 
Valuedass:  (ARC) 

Values:  NIL 

Member  slot:  INPUT-* 

Valuedass:  ((ONE. OF  T  NIL)/ 

Values:  NIL 


Member  slot:  LABEL 
Valuedass;  (STRING) 
Values:  NIL 

Member  slot:  LABEL-OFFSET 
Valuedass:  NIL 
Values:  (ID  in 

Member  slot:  OOF-ARC 
Valuedass:  (ARC) 
Values:  NIL 

Member  slot:  SHAPE 
Valuedass:  NIL 
Values:  NIL 


Unit!  CREATE-SRAPH-NINL-QW 
Members!  NIL 
Subclasses:  NiL 

Gun  slot:  BO 
Valuedass:  <  ME  I  HOD) 

Values!  iL.aMSDA  ( SELF ' 

i  S  f  AS  f  -GRAPH- A  i  NBLN-PR'JC 

Own  slot!  .UNIT, IHAOt 
Valuedass:  NIL 
Values:  NIL 

Jr.it:  CREATE- TREE-WINDOW 
Memoers:  NIL 
Subclasses:  nil 

Own  slot:  DO 
Valuedass:  Nit 
values:  'laf-tDA  •  SELF • 

(DECLARE  (SPECIAL  ).B" 

1 StTQ  KB  NIL) 


“Enter  l.nc'wiedoe  base  to  diri-la.1 

(SLOT.  GRAPH.  k.B  KB  'SUB-ELEMENT  NIL  ( CREATE. KEE. WINDOW)  ’  (HORIZONTAL.- 


Unit:  CATA-IQKEN-TYPE 
Members:  NIL 

Subclasses:  -IUnit  (FON-DATA-TOKEN-nPE  FSN-BRfihHAR-kB) ) 


Unit:  GDA-ACItVEVALUES 

Members!  (IUnit  (ADD -ONLY -OUT PUIS  GDA-S-STEH- 
♦Unit  (AOD-CNLY-INPUTS  GDA-S/3TEH* 
iUnit  (UPDATE-3UB-ELEHENT-P01NIEP  DDh-SssTEH 
♦Unit  >Btt  -LI  BRAR  *  -MEMBERS -MENU  GDA-SrSTEili; 
Subclasses:  NIL 


Unit:  6DA-CQHKAN0S 

Members;  (IUnit  iCREATE-TREE-WINDGW  SDA-SYSTEH)  IUnit  (CFEATE-GRAPH-HINCOH  GSA-SYSTEM) t 

Subclasses:  NIL 

Member  slot:  COMMAND-MENU 
Valued  ass:  (MENU ITEM) 

Values:  ( ("CREATE-TREE-WINDOW" 

♦Unit  (CREATE-TREE-WINDOH  GDA-Si'SFEM) 

"Creates  a  window  that  shows  a  hierchical  dissiav  of  orapns  in  a  Lb") 
("CREATE-GRAPH-HINDOW  IUnit  ( CRE A TE-6RAPH-N I NOON  6DA-SYSTEM)  NIL)) 

Member  slot:  DO 
Valued  ass:  (METHOD) 

Values:  (LAMBDA  (SELF)? 

Meeber  slot:  SELECT-COMMAND 
Valuedass:  (METHOD) 

Values:  (LAMBDA  (SELF) 

(LET  ( (COMMAND-UNIT  (MENU  (GET. SLOT. MENU  SELF  ' COMMAND-MENU) ) U 
(IF  COMMAND-UNi I  IUNITMSG  COMMAND-UNIT  ’DO))>) 

Member  slot:  UPDATE-LOMMAND-MENU 
Valuedass:  (METHOD) 

Values:  i LAMBDA  (SELF) 

’.LET*  ((COMMAND-UNITS  (UNI T.ALLCHiLDPEN  SELF  ’MEMBER))) 

REMOVE. ALL. LOCAL. VALUES  SELF  ’COMMAND-MENU! 

(DOLIST  (CU  COMMAND-UNITS) 


r 


*LET  (UEX1  '.FQRHHl  NIL  "V  (UNI I. NAME  CU))) 
(VALUE  CU) 

(PROMPT  (UNIT .COMMENT  CU))) 

(ADD. VALUE  SELF 

'COMMAND-MENU 

' (.TEXT  .VALUE  , PROMPT)))))) 


Own  slot:  UNAGE. PANEL 
Valuedass:  NIL 

Values:  (IUnit  (IHAGE.PANEL00443  SDA-SYSTEM)) 


Unit:  GDA-SYSTEM-UPDATE-COMMANDS 
Members:  NIL 
Subclasses:  NIL 

Member  slot:  CREATE. INSTANCE 
Valuedass:  NIL 
Values:  NIL 

Member  slot:  CREATE . PROGRAMMATICALLY 
Valuedass:  NIL 

Values:  CREATE. COMPOSITE. CLASS. PROGRAMMAT I  CALL  V 

Own  slot:  GERM 
Valuedass:  NIL 

Values:  (NIL  IUnit  (IMAGE. PANEL  ACTJVEIMAGES) 

NIL 

(368  602  348  147) 

(109  519  347  48) 

EXPAND 

NIL 

((NIL  IUnit  (METHOD. ACTUATOR  ACT  I VE IMAGES) 
NIL 

(384  669  120  51) 

(384  669  209  48) 

EXPAND 

NIL 

NIL 

NIL) 


■.va'v. 
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Own  slot:  UK  AGE.  PANEL 
Valuedass:  NIL 
Values:  NIL 


Unit:  GET-L18RARX-HEMBERS-MENU 
Meabers:  NIL 
Subclasses:  NIL 

Own  slot:  AVSET 
Valuedass:  NIL 
Values:  (LAMBDA 

(SELF  SLOT  VALUE  UNIT  SLOmPEi 
(LET 

(iSUBHEMS  (UNIT. CHILDREN  UNIT  ’SUBCLASS)) 

(IMMEDIATE-MEMBERS  (UNIT. CHILDREN  UNIT  ’MEMBER))) 

(APPEND 

(MAPCAR  (FUNCTION  (LAMBDA  (SUBITEM) 

(LET  ((MENU-TEXT  (FORMAT  NIL 

J  ‘d’* 

(UNIT. NAME  SUBITEM))) 
(VALUE-RETURNED  SUBITEM) 

(PROMPT-MESSAGE  (GET. VALUE  SUBITEM 

’PROMPT-MESSAGE; 1 
(SUB-MENU  (GET. VALUE  SUBITEM  ’MEMBER-MENU) i ) 
'(.MENU-TEXT  .VALUE-RETURNED  .PROMPT-MESSAGE 
(SUBITEMS  .SUB-MENU))))) 

SUBITEMS) 

(MAPCAR 

(FUNCTION  (LAMBDA  (MEMBER) 

(LET  ( (MENUTEXT  (FORMAT  NIL  ""a"  (UNIT.NhME  MEMBER))) 
(VALUE-RETURNED  MEMBER) 
l PROMPT -MESSAGE  (GET. VALUE  MEMBER 

'PROMPT-MESSAGE//; 

'(.MENU TEXT  .VALUE-RETURNED  .PROMPT-MESSAGE;))/ 
IMMEDIATE-MEMBERS)))) 


Unit:  GRAMMAR 

Meabers:  iiUnit  (FGN-GRAMMAR  FGN-GRhMMAR-KB)  > 
Subclasses:  NIL 


xrn- 

Kv 
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Header  slot;  PLAN-LiBRARi 
Valuedass:  ((SUBCLASS. OF  PLAN-LIBRARm 
Values;  NIL 

Header  slot;  PRlfU T IVE-L IBRAR Y 
Valued  ass:  t (SUBCLASS. OF  PRIMITIVE -LIBRARY) > 
Values:  NIL 


Unit:  GRAPH 

Headers;  NIL 

Subclasses:  ftUnit  (PLAN  GDA-SYSTEH)) 

Header  slot:  ADD-SU8-ELEHENI 
Valuedass:  (HETHOO) 

Values:  (LAMBDA  (SELF  CLASS) 

(LET*  ((NEKUNIT  (UN1THSG  CLASS  ' INSTANTIATE)  > 

(PREFIX  (GET. VALUE  CLASS  ’ DEFAUL T -NAME-PREF I X ) ) 

(NEMNAME  (UNiTHSG  SELF  ' GENERATE-SUB-NAHE  PREFIX)) 
(PARENT-SU8-P0IHTER-SLQT  (GET. VALUE  NEkUNIT 

?  PARENT -SUB-POINTER-SLOT ) > ) 

(PUT. VALUE  NEkUNIT  ’SUPER-ELEMENT  SELF) 

(UNITHSG  NEKUNIT  ’ NAME -ELEMENT  NEKNAHE) 

(ADO. VALUE  SELF  PARENT-SUB-POINTER-SLOT  NEKUNIT) 

NEKUNIT 

)) 

Meaber  slot!  CHECK 
Valuedass;  NIL 
Values:  (LAMBDA  (SELF  AGENDA) 

(LET  ( (SUB-ELEMENTS  (GET. VALUE  SELF  ’ SUB-ELEMENTS) ) ! 

(OOLIST  (SE  SUB-ELEMENTS)  (UNITHSG  SE  ’CHECK  AGENDA)))) 

Heaber  slot:  DEFAULT -NAHE-PREF IX 
Valuedass:  NIL 
Values:  (SG) 

Heaber  slot:  DRAH-SUB-ELEHENTS 
Valuedass:  (METHOD) 

Values:  ( LAMBDA  (SELF  WINDOW) 

(LET*  < (PRIMITIVES  (GET. VALUES  SELF  ’SUB-PRIMITIVE) ) 

(GRAPHS  (GET, VALUES  SELF  ’SUB-GRAPH)) 

(INPUTS  (GET. VALUES  SELF  ’SUB-INPUT)) 

(OUTPUTS  (GET. VALUES  SELF  ’SUB-OUTPUT)) 


{ARCS  (GET. VALUES  SELF  'SUB-ARC))) 

(D0L1ST  (SUB  (APPEND  PRIMITIVES  GRAPHS  INPUTS  OUTPUTS  ARCS!) 

(UNITNSG  SUB  'DRAW  WINDOW)))) 

Neater  slot:  GENERA TE-SUB-NANE 
Valueclass:  (METHOD) 

Values:  (LAMBDA  (SELF  PREFIX) 

(LET  ((COUNT  (1+  -GET. VALUE  SELF  ’ SUB-ELEMENT-CQUN! ) ) ) ) 

(PUT. VALUE  SELF  ’SUB-ELEMENT-COUNT  COUNT! 
t MAKE-SYMBOL  (FORMAT  NIL  “Vd"  PREFIX  COUNT)))) 

Meaber  slot:  GRAMMAR 
Valueclass:  (GRAMMAR) 

Values:  (FGN-GRAMNAR) 

Meaber  slot:  PARENI-SUB-PQ1NIER-SLU1 
Valueclass:  NIL 
Values:  (SUB-GRAPH) 

Meaber  slot:  REMOVE-SUB-ElEMEIH 
Valueclass:  (METHOD) 

Values:  (LAMBDA  (SELF  SUBELEMENU) 

Meaber  slot:  SELECTABLE-I TEN-TYPE 
Valueclass:  NIL 
Values:  CGRAPH-I TEN) 

Meaber  slot:  SUB-ARC 
Valueclass:  (ARC) 

Values:  NIL 

Meaber  slot:  SUB-ELEMENT -COUNT 
Valueclass:  (INTEGER) 

Values:  IB) 

Meaber  slot:  SUB-GRAPH 
Valueclass:  (GRAPH) 

Values:  NIL 


/> 


(leaser  slot;  SUB-POINTERS 
Valuedass;  NIL 

Values:  (SUB-ARC  SUB-GRAPH  SUB-PRIHJ1 1VE) 

Mesoer  slot:  SUB-PRIMITIVE 
Valuedass:  (PRIMITIVE) 

Values:  NIL 


Unit:  GRAPH-ELEMENT 

(leabers:  NIL 

Subclasses:  (iUnit  (ARC  GDA-SYSTEN)  tUnit  (NUDE  GDA-SfSIEM)  #Ur«it  (JUNCTION  GDA-SiSTEM)) 

Meaber  slot:  CHECK 
Valuedass:  (METHOD) 

Values’.  (LAMBDA  (SELF  AGENDA)) 

Meaber  slot:  DEFAULT-NAME-PREFIX 
Valuedass;  NIL 
Values:  iGE) 

Meaber  slot:  DELETE 
Valuedass;  tMETHOD) 

Values;  (LAMBDA  (SELF) 

•,  (DQLIST  (SUB  (GET, VALUES  SELF  ’SUB-ELEMENT))  (UNITMSG  SUB  ’DELETE)) 

**  (LET  ((PARENT  (GET. VALUE  SELF  ’SUPER-ELEMENT)!) 

(IF  PARENT 

(LET  ((SUB-POINTER-SLOT  (GET. VALUE  SELF  ’ PARENT -SUB-POINTER-SLOT) ) ) 

(IF  SUB-POINTER-SLOT  (REMOVE. VALUE  PARENT  SUB-POINTER-SLOT  SELF)).-)) 
(UNITDELETE  SELF)) 

Meaber  slot:  DRAM 
Valuedass:  (METHOD) 

Values:  NIL 

Meaber  slot:  FIRSTNAME 
Valuedass:  NIL 
Values:  NIL 
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Member  slot:  INSTANTIATE 
Valued  ass;  (METHOD) 

Values;  (LAMBDA  (SELF) 

(CREATE. UNIT  (GENSYM  'E)  NIL  NIL  SELF)) 

Member  slot:  NAME-ELEMENT 
Valued  ass:  (METHOD) 

Values:  (LAMBDA  (SELF  (OPTIONAL  NEWFIRSTNAME) 

(LET*  l (FIRSTNAME  (IF  NENFIRSTNAME 
NEMFIRSTNAME 

(SET. VALUE  SELF  ’FIRSTNAME))) 

(OLDNAME  (UNIT. NAME  SELF)) 

(PARENT  (6ET. VALUE  SELF  ’SUPER-ELEMENT)) 

(NEWNAME  (IF  PARENT 

(MANE-SYMBOL  (FORMA)  NIL 

“'a  'a" 

FIRSTNAME 

(UNIT, NAME  PARENT))) 

FIRSTNAME)!) 

(COND  ((NEO  NEWNAME  OLDNAME) 

(UN1TFENAME  SELF  NEWNAME) 

(RUT. VALUE  SELF  ’FIRSTNAME  FIRSTNAME) 

(DOL1ST  (CHILD  (GET. VALUES  SELF  ’ SUB-ELEMENT  f  ? 

(UN IT MSG  CHILD  ’ NAME-ELEMEN f ) ) ) ) 

NEWNAME 

)  ,1 

Member  slot:  PARENT-SUB-POINTER-SLOl 

Valueclass:  ((ONE. OF  SUB-INPUT  SUB-OUTPUT  SUB-GRAPH  SUB-PRIMITIVE  SUB-ARC) ) 
Values:  NIL 

Member  slot:  SELECTABLE-ITEM-TYPE 

Valueclass:  ((ONE. OF  :PRIMiTIVE-JTEM  : GRAPH- ITEM  : INPUT-1 TEM  : OUTPUT- 1 T EM) ) 
Values’.  NIL 

Member  slot:  SUB-POINTERS 
Valueclass:  NIL 
Values:  NIL 

Member  slot:  SUPER-ELEMENT 
Valueclass:  (NODE) 

Values:  NIL 
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unit:  IMAGE. PANELM44J 

Members:  NIL 

Subclasses:  NIL 

Own  slot:  BORDER 
Valuedass:  NIL 
Values:  12 

Own  slot:  HEIGHT 
Valuedass;  NIL 
Values:  111 

Own  slot:  IMAGE. WAS. PAINTED 
Valuedass:  NIL 
Values:  (MIL) 

Own  slot:  IMAGES 
Valuedass:  NIL 

Values:  ItUmt  (METHOD.ACTUATQR00577  6DA-SYSTEM) 
♦Unit  (METHOD. ACTUATQR00474  60A-SYSTEM) ) 

Own  slot;  OBJECT. DISPLAYED 
Valuedass:  NIL 
Values:  m  (GDA-SYSTEN) 

Own  slot:  REGION 
Valuedass:  NIL 
Values:  (325  623  338  111) 

Own  slot:  TITLE 
Valuedass:  NIL 
Values:  “GDA  User  Cosuaands” 

Own  slot:  TITLEFONT 
Valuedass:  NIL 
Values:  FONFSIHLIBB 
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Own  slot;  TOPUNIT 
Valuedass:  NIL 

Values:  ftUnit  ( SDA-COMMANDS  GDA-SYSTEM) 

Own  slot:  WIDTH 
Valuedass:  NIL 
Values:  338 

Own  slot:  WINDOW 
Valuedass:  NIL 

Values;  IsIWIN  Iwin  4  1&31335Z  deexposed) 


Unit:  IMAGES 

Members:  flUnit  ( IMAGE, RANEL00443  SDA-SVSTEH)  lUmt  (METHOD. ACTUATDR00577  GDA- SYSTEM) 

iUmt  (METHOD. ACTUATQR00499  GDA-SYSTEM) 
lUmt  (METHOD. ACTUATOR00474  GDA-SYSTEM) ) 

Subclasses:  NIL 

Own  slot:  DELETE 
Valuedass:  METHOD 
Values'.  DELETE. ALL. IMAGES 

Own  slot:  DELETE. ALL. IMAGES 
Valuedass:  METHOD 
Values:  DELETE. ALL. ItlfiSES 

Own  slot:  DONT. RECREATE . IMAGES. AF TER , K8LOAD 
Valuedass:  (ONE. OF  T  NIL  ASKUSER) 

Values:  ASKUSER 

Own  slot:  RECREATE. ALL. IMAGES 
Valuedass:  method 
Values:  RECREATE. ALL. IMAGES 


Own  slot:  SAVE. ALL. IMAGES 
Valuedass:  METHOD 
Values:  SAVE. ALL. IMAGES 
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Qha  slot:  USER. DELETE. ALL, IMAGES 
Valued  ass:  METHOD 
Values:  USER. DELETE. ALL, IMAGES 

Own  slot:  USER. RECREATE . ALL. IMAGES 
Valuedass:  METHOD 
Values:  USER. RECREATE. ALL. IMAGES 


Unit:  IN-CONNECTOR 

Meabers:  NIL 

Subclasses:  NIL 

Meaber  slot:  CONNECT-PUINI-OFFSET 
Valuedass:  NIL 
Values:  ((28  6.'! 

Meaber  slot:  DEFAUL T-NAME-PREF 1 X 
Valuedass:  NIL 
Values:  (1) 

Meaber  slot:  1NPUT-P 
Valuedass:  NIL 
Values:  (T) 

Meaber  slot:  LABEL 
Valuedass:  NIL 
Values:  ("in") 

Meaber  slot:  LABEL-OFFSET 
Valuedass:  NIL 
Values:  (14  U) 

Meaber  slot:  PARENT-SUB-POINTER-SLOT 
Valuedass:  NIL 
Values:  (SUB-INPUT) 


Member  slot:  SHAPE 
Valuedass:  NIL 

Values;  1(0  0)  (25  0)  (28  6)  (25  12)  (0  12)  (0  0)) 


Unit:  IN-PIN 

Nesbers:  NIL 

Subclasses:  (lUmt  (FGN-IN-PIN  FGN-6RAMMAR-KB) ) 

Meaber  slot:  CONSTANT-INPUT 
Valuedass:  ((ONE. OF  T  NIL)) 

Vaiues:  NIL 

Hesber  slot:  DEFAULT-NAME-PREFIt 
Valuedass:  NIL 
Values:  (1) 

Hesber  slot:  IN-ARC 
Valuedass:  (ARC) 

Values:  NIL 

Hesber  slot:  PARENT -SUB-POINTER-SLOT 
Valuedass:  NIL 
Values:  (SUB-INPUT) 

Hesber  slot:  SELECTABLE- 1  TEH- T  . PE 
Valuedass:  NIL 
Values:  ( : INPUT- £  TEN  > 


Unit:  I 0-PIN 
Nesbers;  NIL 

Subclasses:  (lUnit  (IN-PIN  6DA-SVSTEH)  *Umt  (0U1-PIN  SOA-brSlEH)) 

Hesber  slot:  LEGAL-DATA- TOKENS 
Valuedass:  (OATA-TOKEN-TVPE) 

Values;  NIL 


Unit:  JUNCTION 
Members:  NIL 

Subclasses:  (iUnit  (10-PI*  GDA-SYSTEM)  lUnit  (CONNECTOR  GDA-SYSTEM)) 

Member  slot:  CALC-DISPLAY-HEIGHT 
Valuedass:  (METHOD) 

Values;  (LAMBDA  (SELF  WINDOW ) I 

Me»ber  slot:  CALC-DISPLAY-WIDTH 
Valuedass:  (METHOD) 

Values:  (LAMBDA  (SELF  WINDOW)) 

Member  slot:  CONNECT-POINT 
Valuedass:  NIL 
Values:  NIL 

Member  slot:  DELETE 
Valuedass:  NIL 

Values:  ((BEFORE  (LET  ((IN-ARCS  (GET. VALUES  SELF  ’IN-ARC!) 

(OUT-ARCS  (GET. VALUES  SELF  ’OUT-ARC) )) 

(DOLIST  (IN  IN--RCS)  (UNITMSG  IN  ’DELETE)) 

(DOLIST  (OUT  OUT-ARCS)  (UNITMSG  OUT  ’DELETE) ) ) - 


Member  slot:  INPUT-POSITION 
Valuedass:  NIL 
Values:  NIL 

Member  slot:  OUTPUT-POSITION 
Valuedass:  NIL 
Values:  NIL 


Member  slot:  POSITION 
Valuedass:  NIL 
Values:  ( (0  20) ) 


Meeber  slot;  SELECT-ARC-FROM-SLOF 
Valuedass:  (METHOD) 

Values:  (LAMBDA 

(SELF  SLOl  40PIIQNAL  LABEL) 

(LET 

((ARCS  (GET. VALUES  SELF  SLOT))) 

(IF 

!'  1  (LENGTH  ARCS)) 

(LET 

MAL1ST 

SMAPCAR 

(FUNCTION  (LAMBDA  (ARC) 

ICONS  (LET*  ((FROM  (GET. VALUE  ARC  ’ FROH-JUNCT ION) ) 

(TO  (GET. VALUE  ARC  ’ TQ-JUNCTION) I 
(TQ-NODE  (GET. VALUE  TO  ’SUPER-ELEMENT))) 
(FORMAT  NIL 

“fro#  'a  to  'a.'a" 

(GET. VALUE  FROM  ’FIRSTNAME) 

(GET. VALUE  TO  ’FIRSTNAME) 

(GET, VALUE  TO-NODE  ’FIRSTNAME) ) « 

ARC))) 

ARCS) ) ) 

(SELECT-FROM-ALIST  AL1ST  LABEL)) 

(CAR  ARCS)))) 


Unit:  LIBRARY 
Menbers:  NIL 

Subclasses:  (iUmt  (PRIMITIVE-LIBRARY  6DA-SVSTEM)  DUnit  (PLAN-LIBRARY  GDA-SYSTEMi! 

Meeber  slot:  GET -MENU- ITEM 
Valuedass:  (ME  I  HOD) 

Values;  (LAMBDA  (SELF) 

(LET  ((TEXT  (FORMAT  NIL  ’'a'1  (UNIT. NAME  SELF))! 

(VALUE  SELF) 

(PROMPT  (FORMAT  NIL  “Instantiate  V  (UNIT. NAME  SELF)))) 

’(.TEXT  .VALUE  .PROMPT!)) 

Member  slot:  GET-MENU-SUBITEMS 
Valuedass:  (METHOD) 

Values:  (LAMBDA 
(SELF) 

(LET* 

((SUBCLASSES  (REVERSE  (UNIT. CHILDREN  SELF  ’SUBCLASS))! 

(MEMBERS  (REVERSE  (UNIT. CHILDREN  SELF  ’MEMBER))! 
i SUBCLASS-ITEMS  (IF  SUBCLASSES 

( MAPCAR  (FUNCTION  (LAMBDA  (SC! 


SUBCLASSES) > ) 


(UNI  MSG  SC 

’  GET-HENU-SUBITEMS) ) ) 


MEMBER- HENS  (IF  MEMBERS 

(HAPCAR  (FUNCTION  (LAMBDA  (SC) 

(UNITMSG  SC  ’GET -MENU-ITEM))) 

MEMBERS))) 

(TEIT-VALUE-PRQNPT  1  (, (UNIT, NAME  SELF)  .SELF  'See  sub  #enu">)> 

(COND  HAND  SUBCLASS- iTEMS  MEMBER-ITEHS) 

(APPEND  TEXT-VALUE-PROMPT 

(LIST  (CONS  ’SUBITEMS 

(APPEND  SUBCLASS- 1  TENS  MEMBER-HEMS))))) 

(SUBCLASS- 1  TENS 
(APPEND  (EXT -VALUE-PROMPT 

'((SUBITEMS  .  .SUBCLASS-ITEMS))); 

MEMBER-ITEMS 
(APPEND  TEXf-VALUE-PROMPT 

'((SUBITEMS  .  .MEMBER-ITEMS)))).!)! 

Menber  slot:  MEMBER-MENU 
ValuedassI  (MENUITEN) 

Values:  NIL 

Meeber  slot:  MEMBER-MENU- TEST 
Valuedass:  NIL 
Values:  NIL 

Metber  slot:  SELECT-FRQM-MENU 
Val uecl ass:  (METHOD) 

Values:  I  LAMBDA  (SELF) 

(MENU  (GET. SLOT. MENU  SELF  ’MEMBER-MENU))) 

Menber  slot:  UPDATE-MEMBER-MENU 
Valuedass:  (METHOD) 

Values:  (LAMBDA  (SELF) 

(LET  ((SUBCLASSES  (UNIT. CHILDREN  SELF  ’SUBCLASS)) 

(MEMBERS  (UNIT. CHILDREN  SELF  ’MEMBER))) 

(REMOVE. ALL. LOCAL. VALUES  SELF  ’MEMBER-MENU) 

(DOLIST  (SC  SUBCLASSES) 

(ADD. VALUE  SELF  ’MEMBER-MENU  (UNITMSG  SC  ’GET -MENU -SUB ITEMS) ) 
(DOLIST  !M  MEMBERS) 

(ADD. VALUE  SELF  ’MEMBER-MENU  (UNITMSG  M  ’ SET -MENU-ITEM ) ) ) ! ) 


Unit;  tIEIHOO. AC'UAIURO04’4 
Menders:  NIL 
Subclasses;  NIL 

Own  slot:  BORDER 
Valuedass:  NIL 
Values:  4 

Own  slot:  F0N1 
Valued  ass:  NIL 
Values:  F0N1S:HL6 

Own  slot;  HEIGHT 
Valuedass;  NIL 
Values:  36 

Own  slot:  IMAGE. HAS. PAINTED 
Valuedass;  NIL 
Values;  T 

Own  slot:  OBJECT. DISPLAYED 
Valuedass:  NIL 

Values:  (Slot  (DO  CREATE-GRAPH-N1NOOW  G0A-SYS1EH  OWN) 

Own  slot:  REGION 
Valuedass:  NIL 
Values:  NIL 

Own  slot:  SUPER. IMAGE 
Valuedass:  NIL 

Values:  »Umt  : IMAGE. PANEL0B443  GBA-SY5TEH) 

Own  slot:  TITLE 
Valuedass:  NIL 

Values;  "Create  a  new  Grash  Hindow" 
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Own  slot;  T1TLEF0NT 
Valued dss:  NIL 
Values:  FONTS:HLli?B 

Own  slot:  TOPUMIT 
Valued  ass;  NIL 
Values;  (NIL) 

Own  slot;  VALUE, WAS. SAVED 
Valuedass:  NIL 
Values;  T 

Own  slot:  WIDTH 
Valuedass:  NIL 
Values;  182 

Own  slot:  WINDOW 
Valuedass:  NIL 

Values:  IdWlN  I  win  S  16314826  deexoosed 


Unit:  METHOD. ACTUAT0RD8499 

Menbers:  NIL 

Subclasses:  NIL 

Own  slot”.  BORDER 
Valuedass:  NIL 
Values:  4 

Own  slot:  FONT 
Valuedass;  NIL 
Values:  F0NTS:HL6 

Own  slot:  HEISHT 
Valuedass:  NIL 
Values:  51 


Own  slat!  IMAGE. WAS. PAINTED 
Valuedass;  NIL 
Values:  T 

Own  slot:  OBJECT. DISPLAYED 
Valuedass:  NIL 

Values:  ISlot  (SELECT-COMMAND  GDA-COHHANDS  GDA-SYSTEM  MEMBER) 

O*o  slot:  REGION 
Valuedass:  NIL 
Values:  NIL 

Own  slot:  TITLE 
Valuedass:  NIL 

Values:  "GCA-COMMANDS’s  SELECT-COMMAND" 

Own  slot:  TITLEFONT 
Valuedass:  NIL 
Values:  FONTS: HLltfB 

Own  slot:  TOPUNIT 
Valuedass;  NIL 
Values:  (NIL) 

Own  slot:  VALUE. WAS. SAVED 
Valuedass;  NIL 
Values;  T 

Own  slot:  WIDTH 
Valuedass:  NIL 
Values:  109 

Own  slot:  WINDOW 
Valuedass:  NIL 

Values:  IdWIN  Iwin  l  16313124  deexooseO: 
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Own  slot:  BORDER 
Valuedass:  NIL 
Values:  4 


Own  slot:  FONT 
Valuedass:  NIL 
Values:  FONTS: HL 10 


Own  slot:  HEIGHT 
Valuedass;  NIL 
Values:  41 


Own  slot;  IMAGE. WAS. PAINTED 
Valuedass:  NIL 
Values;  T 


Own  slot:  OBJECT. DISPLAYED 
Valuedass;  NIL 

Values:  (Slot  'DO  CREATE- TREE-W1ND0U  GDA-3YSTEM  OWN- 


Own  slot:  REGION 
Valuedass:  NIL 
Values:  NIL 


Own  slot:  SUPER. IMAGE 
Valuedass:  NIL 

Values:  (Unit  (IKA6E.PANELM443  GDA-SYS1EM) 


Own  slot:  TITLE 
Valuedass:  NIL 

Values:  "Create  a  window  ot  showino  sub-element  relations" 


Own  slot:  TITLEFONT 
Valuedass:  NIL 
Values:  FONTS:HL10B 


Own  slot:  TOPLINIT 
Valuedass:  NIL 
Values:  (NIL- 
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Own  slot:  VALUE. WAS. SAVED 
V a  1  u e cl  a s s :  NIL 
Values:  T 

Own  slot:  WIDTH 
Valued  ass :  NIL 
Values:  322 

Own  slot:  WINDOW 
Valuedass:  NIL 

Values:  K1WIN  Iwin  4  1631340?  deexposed) 


Unit:  NODE 
Members:  NIL 

Subclasses:  iiUnit  (GRAPH  GDA-SYSTEM)  «Umt  (PRIMITIVE  GDA-SVSTEM) ) 

Member  slot:  ADD-INITIAL -SUB-ELEMENT 
Valuedass:  (METHOD) 

Values:  (LAMBDA  ' SELF  FIRSTNAME  CLASS  SLOT-POINTER) 

(ADD. VALUE  SELF 

’ INITIAL-SUB-ELEMENT 

'(.FIRSTNAME  . (UNI TREFERENCE  CLASS)  .SLOT-POINTER) ) ) 

Member  slot!  CALC-DISPLAV-HEIGHT 
Valuedass:  (METHOD) 

Values:  (LAMBDA  (SELF  WINuQW) 

50) 

Member  slot:  CALC-DISPLAY-WIDTH 
Valuedass:  (METHOD) 

Values:  (LAMBDA  (SELF  WINDOW) 

30) 

Member  slot:  DRAW 
Valuedass:  (METHOD) 

Values:  (LAMBDA  (SELF  WINDOW) 

(SEND  WINDOW  : DRAW-NODE  SELF)! 
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Hctber  slot:  I MI T I AL-SUB-ELEMENT 
Valueelass:  (LIST! 

Values:  NIL 

Meeber  slot:  INSTANTIATE 
Valueelass:  NIL 
Values:  (LAMBDA  (SELF) 

(LET  KNEWUNIT  (CREATE. UNIT  (SENSYM)  NIL  NIL  SELF))) 

(DOLIST  TSUB  (GET. VALUES  SELF  ’INITIAL-SUB-ELEMENT)) 
(LET*  ((FIRSTNAME  (FIRST  SUB)) 

(CLASS  (SECOND  SUB)) 

(SUBELEMENT  (UNITMSG  CLASS  ’INSTANTIATE)) 
(SUB-POINTER  (THIRD  SUB))) 

(ADD. VALUE  NEMUN1T  SUB-POINTER  SUBELEMENT) 
(PUT. VALUE  SUBELEMENT  ’SUPER-ELEMENT  NEWUNIT) 
(UNITMSS  SUBELEMENT  'NAME-ELEMENT  FIRSTNAME!)! 

NEWUNIT 

)) 

Menber  slot:  LABEL 
Valueelass'.  (STRING) 

Values:  ("  •> 

Meeber  slot:  POSITION 
Valueelass:  NIL 
Values:  NIL 

Menber  slot:  SUB-ELEMENT 
Valueelass:  (GRAPH-ELEMENT) 

Values:  NIL 

Member  slot:  SUB-INPUT 
Valueelass:  (JUNCTION) 

Values;  NIL 

Member  slot:  SUB-OUTPUT 
Valueelass:  (JUNCTION) 

Values:  NIL 


Meaber  slot:  SUB-POINTERS 
Valued  ass:  NIL 

Values:  (SUB-ELEMENT  SUB-INPUT  SUB-OUTPUT) 


Unit:  OUT-CONNECTOR 
Members:  NIL 
Subclasses:  NIL 

Member  slot:  CONNECT-POINT-OFFSET 
Valuedass:  NIL 
Values:  1(3  6)) 

Member  slot:  DEFAUir-NflME-PREFI)! 

Valuedass:  NIL 
Values:  (0) 

Meaber  slot:  INPUT-P 
Valuedass:  NIL 
Values:  (NIL) 

Member  slot:  LABEL 
Valuedass:  NIL 
Values:  < "out" ) 

Member  slot:  LABEL-OFFSET 
Valuedass:  NIL 
Values:  ( (6  2) ) 

Member  slot:  PARENT-SUB-POINTER-SLCT 
Valuedass:  NIL 
Values:  (SUB-OUTPUT) 

Member  slot:  SHAPE 
Valuedass:  NIL 

Values:  1(0  0)  (30  0)  (30  12)  (0  12)  (3  6)  SB  0)) 


Unit:  OUT-PIN 
Members:  NIL 

Subclasses:  (lUnit  (F6N-0UT-PIN  FGN-6RAMMAR-M))) 


tlesber  slot:  DEFAULT-NAHE-PREF1X 
Valuedass:  NIL 
Values;  (0) 

Meaber  slot:  OUT-ARC 
Valuedass:  (ARC) 

Values:  NIL 

Heaber  slot:  PARENT-SUB-POINTER-SLOT 
Valuedass:  NIL 
Values:  (SUB-OUTPUT) 

Heaber  slot:  SELECTABLE- 1  TEH-TYPE 
Valuedass:  NIL 
Values:  C0UTPUT-ITEM5 


Unit:  PLAN 
Neabers:  NIL 
Subclasses:  NIL 

Heaber  slot:  DEFAULT -NANE-PREF IX 
Valuedass:  NIL 
Values:  (PLAN) 

Heaber  slot:  NIL 
Valuedass:  NIL 
Values;  NIL 


Unit:  PLAN-LIBRARY 
Heabersi  NIL 
Subclasses:  NIL 


Unit:  PRIMITIVE 
Heabers:  NIL 

Subclasses:  (iUmt  (ROBOT-ARM  F6H-PR1MITI VE-LIBRARY-KB) 
iUnit  (0FFBUTT0NLI6HTS  FGN-PRIHITIVE-LIBRARY-KB) 
•Unit  (HOSTOUT  FGN-PRIHITIVE-LIBRARY-KB) 

(Unit  (HCPIP  FGN-PRIHITIVE-LIBRARY-KB) 


♦Unit  (FIABEU  FSN-PRIHl TIVE-L1BRARY-KB) 

♦Unit  (FLABEL.1-12  F6N-PRIMITI VE-L I BRARY-KB ) 
♦Unit  (FKEYS  F6N-PRIMI TIVE-LIBRAR i-KB) 

♦Unit  (FFPLOT  F SN-PR 1 M 1 T I VE-L i BRAR V -K8 J 
♦Unit  (F.ZVECTQR  F6N-PRIHITIVE-L1BRARY-KB) 

♦Unit  (F.ZRGTATE  FGN-PRINITIVE-LIBRARY-KBi 
♦Unit  (F.YVECTOR  FSM-PRIMITIVE-LIBRARY-KB) 

♦Uni t  IF.YR0TATE  FGN-PR JMJ II VE-L I BRARY-KB) 

♦Unit  (F . XVECTOR  F8N-PRIHI TIVE-LIBRARY-KB) 

♦Unit  (F.XROTATE  FGN-PRINITIVE-LIBRARY-KB! 

♦Unit  (F.KORC  F6N-PR1MI TIVE-LIBRAR Y-KB5 
♦Unit  tF.XUR  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.XFORHDATA  FGN-PRINITIVE-LIBRARY-KB) 
♦Unit  (F. WINDOW  FGN-PRIMIT I  VE-L  JBR'ARY-KB  J 
♦Unit  (F.VECC  F6N-PRII11 T I VE-LI BRARY-KB) 

♦Unit  tF. VEC.EX1RACT  FGN-PRIMIT I VE-LIBRARY-K&) 
♦Unit  (F.VEC  FGN-PRIMIT IVE-LIBRARY-KB) 

♦Unit  (F, TRANS. SIRING  FBN-PRIMI T 1 VE-LIBRARY-fcB) 
♦Unit  (F. TIMEOUT  FGN-PRIrtlTJVE-liBRARY-XS) 

♦Unit  (F. TAKE. STRING  FGN-PR I NI T I VE-L 1 BRhR  Y -KB ) 
♦Unit  IF. SYNC  FBN-PRIMI TIVE-LIBRAR Y-KBi 
♦Unit  (F.SU8C  FGN-PR IH1TIVE-LI8RARY-K8) 

♦Unit  iF.SUB  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  IF. STRING. TO. NUN  FGN-PR I M I T I VE -L I BRAR V -KB ) 
♦Unit  (F.SQROQT  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F. SPLIT  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.SINCOS  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F. SCALE  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.ROUTEC  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F. ROUTE  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F. ROUND  FGN-PRINITIVE-LIBRARY-KB! 

♦Unit  (F. RANGE. SELECT  FGN-PRINITIVE-LIBRARY-KB) 
♦Unit  (F. PUT. STRING  FGN-PRINITIVE-LIBRARY-KB) 
♦Unit  (F, PRINT  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F. POSITION. LINE  F6N-PRIHITIVE-LJBRARV-KB) 
♦Unit  (F.PICKINFO  FGN-PRINITIVE-LIBRARY-KB! 

♦Unit  (F.PASSTHRU  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F. PARIS  FGN-PRINITIVE-LIBRARY-KB! 

♦Unit  (F.ORC  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.OR  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.NOT  FGN-PRINITIVE-LIBRARY-KB! 

♦Unit  IF. MOP  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.NEC  FGN-PRINITIVE-LIBRARY-KB < 

♦Unit  IF.  ME  FSN-PR 1MIT I VE-L IBRARV-kB) 

♦Unit  (F.NULC  FGN-PRINITJVE-LIBRARY-K8) 

IUr.it  iF.NUL  FGN-PRIHITIVE-LIBRAR(-KB) 

♦Unit  (F.HODC  FGN-PRINIUVE-LI8RARY-K&) 

♦Unit  IF. NOD  FGN-PRIN1 I IVE-LlBRARv-KB) 

♦Unit  (F.NCONCATENATE  FGN-PRINITIVE-LIBRARv-KB; 
♦Unit  IF.MATRIX4  FGN-PRIMI T1 VE-L IBPARY-k 6 > 

♦Unit  t F . MATR I X 3  FGH-PRINITIVE-LiBRARY-KB) 


♦Unit  IF.NATRIX2  FGN-PRIHI T IVE-LIBRARY-KB) 

(Unit  IF. LTC  F6M-PR1MITIVE-LI8RARY-KB) 

♦Unit  (F.LT  FGN-PRIHITIVE-LIBRARV-KB) 
ftUnit  IF.LOOKFRQH  FGN-PR1MITIVE-LIBRARY-KB) 

♦Unit  (F.LQQKAT  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.LINEEDJTDR  F8M-PRIMITIVE-LIBRARY-KB) 
♦Unit  (F.LIH1I  FGN-PRIHITIVE-LIBRARY-KB! 

♦Unit  IF. LEH6HT. STRING  FGN-PR1MI1 1VE-L1BRARY-KB) 
♦Unit  (F.LEC  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.LE  FGN-PRi«n  1VE-LIBRARY-KB) 

♦Unit  IF. LBL. EXTRACT  FGN-PRIMI TI VE-LIBRARY-KB; 
♦Unit  (F. LABEL  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  IF. INPUTS. CHOOSE  F8M-PRIMITIVE-L1BRAR Y-KB) 
♦Unit  (F.GTC  FGN-PRIfllTIVE-LIBRARY-KB) 

♦Unit  (F.ST  FGN-PRIHITIVE-LIBRARY-KB! 

♦Unit  (F.GEC  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.GE  FGN-PRIHITIVE-LIBRARY-K8) 

♦Unit  (F.GCE  F6N-PR I N I T I VE-L I BR AR Y-KB ) 

♦Unit  (F. GATHER. STRING  FGN-PRIHITIVE-LIBRARY-KB) 
♦Unit  (F.FOV  FGN-PR IMITI VE-LIBRARY-KB) 

♦Unit  (F. FLOAT  FGN-PRIHITIVE-L1BRARY-KB) 

♦Unit  (F.FIX  FGN-PRlflITIVE-LIBRARY-KB> 

♦Unit  IF. FINC. STRING  FGN-PRIHITIVE-LIBRARY-KB) 
♦Unit  (F. FETCH  FGN-PRIRITIVE-L1BRARY-KB) 

♦Unit  IF.EQC  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.EQ  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  IF. EDGE. DETECT  FGN-PRIHITIVE-LIBRARY-KB) 
♦Unit  (F.D2ROTATE  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.DYROTATE  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.DXROTATE  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.DSCALE  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  IF.DIV  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.DIFC  F6N-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.DELETA  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.CVEC  F6N-PRINI TIVE-LIBRARY-KB) 

♦Unit  (F.CSUB  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  IF.CSCALE  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.CROUTE  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.CROTATE  FGN-PR I HI T I VE-LIBRARY-KB ) 

♦Unit  IF. CONSTANT  F6N-PR I  HI  T 1 VE-U  BRARY-KB ) 

♦Unit  (F.CONCATENTATEC  FGN-PRINITIVE-LIBRARY-KB) 
♦Unit  (F. CONCATENATE  FGN-PRINITIVE-LIBRARY-KB) 
♦Unit  (F.C0NP.STRIN6  FGN-PRINITIVE-LIBRARY-KB) 
♦Unit  IF. COLOR  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.CHUL  F6N-PRINI TIVE-LIBRARY-KB) 

♦Unit  (F.CLTICKS  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  IF.CLT  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.CLFRAHES  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.CLE  FGN-PRINITIVE-LIBRARY-KB) 

♦Unit  (F.CLCSECONDS  FGN-PR I H I T I VE-L I BPAR V -K B ) 
♦Unit  (F.CHARNASK  FGN-PRIHITIVE-LIBRARY-KB) 


m 


K- 


V 


♦Unit 

#Umt 

♦Unit 

lUnit 

♦Unit 

lUnit 

♦Unit 

lUnit 

lUnit 

lUnit 

♦Unit 

•Unit 

lUnit 

lUnit 

•Unit 

♦Unit 

lUnit 

♦Unit 

lUnit 

♦Unit 

♦Unit 

lUnit 

♦Unit 

♦Unit 

♦Unit 

♦Unit 

♦Unit 


Member  slot:  OEFINE-PRIillTIVE 
Valuedass:  (METHOD) 

Values:  NIL 


Meaber  slot:  LABEL 
Valuedass;  NIL 
Values:  Cduaav") 


(F.CHARCQNVERT  F6N-PR1MI T I VE-LI BP.ARV-KB) 
(F.CGT  FGN-PRIfUTIVE-LIBRARV-KB) 

(F, CEDING  FGN-PRIMITIVE-LIBRARY-KB) 

(F.CD1V  FGN-PR 1 MI T 1 VE-L 1 BR ARV -K B ) 
(F.CCONCATENATE  FGN-PRIMITIVE-LIBRARY-KB) 
(F.CBROUTE  FGH-PRIM1 T I VE-L1 BRARY-KB) 
(F.BROUTEC  FGN-PRIMITIVE-LIBRARY-KB) 
(F.BROUTE  FGN-PRIMITIVE-LIBRARY-KB) 

(F. BOOLEAN. CHOOSE  FGN-PRIMITIVE-LIBRARY-KB) 
(F. AVERAGE  FGN-PRIMITIVE-LIBRARY-KB) 
(F.ATSCALE  FGN-PRIMITIVE-LIBRARY-KB) 

( F .  AND  FGM-PR 1  Ml  T I  VE-L  I BRAR  Y  -KB ) 

(F.AOOC  FGN-PRIMiriVE-LIBRARY-KB) 

(F.ADD  FGN-PRIMITIVE-LIBRARY-KB) 

(F. ACCUMULATE  FGN-PRI MI T I VE-LIBRAR i -KB) 
(CTREE  FGN-PRIMITIVE-LIBRARY-KB) 

(DLABEL.1-8  FGN-PRIMITIVE-LIBRARY-KB! 

(DIALS  FGN-PRIMITIVE-LIBRARY-KB) 

(CURSOR  FGN-PRIMITIVE-LIBRARY-KB) 

(CLEAR. LABELS  FGN-PRIMITIVE-LIBRARY-KB) 
(BUTTONSIN  FGN-PRIMITIVE-LIBRARY-KB! 
(TABLETOUT  FGN-PRIMITIVE-LIBRARY-KB) 
(TABLETIN  FGN-PRIMITIVE-LIBRARY-KB) 
(SPECKEYS  FGN-PRIMITIVE-LIBRARY-KB) 

( P I CK .  LOCA  T I  ON  FGN-PR  I M I T I  VE-L  I  BR  AR  V  -KB ) 
(PICK  FGN-PRIMITIVE-LIBRARY-KB) 

(KEYBOARD  F6N-PRIMI TIVE-LIBRARY-KB) ) 


Meaber  slot:  DEFAULT-NAME-PREFIX 
Valuedass;  NIL 
Values:  (P) 


Meaner  slot:  PARENT-SUB-POINTER-SLOT 
Valuedass;  NIL 
Values:  (SUB-PRIMITIVE’- 
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Member  slot:  SELECTABLE- ITEM-TYPE 
Valuedass:  NIL 
Values:  <  .‘PRIMITIVE-1  TEH) 


Unit:  PRIMITIVE-LIBRARY 
Metbersi  NIL 

Subclasses:  <*Unit  tFGN-PRIMll IVE-LIBRARY  FGM-PRIMI TIVE-LIBRARY-KB) ) 


Unit:  UPDATE-SUB-ELEMENT-POINTER 
Members:  NIL 
Subclasses:  NIL 

Own  slot:  AVPUT 
Valuedass;  NIL 

Values:  (LAMBDA  (SELF  SLOT  NEWVALUE  OLDVALUE  UNIT  SLOTTYPE) 

(DDL  1ST  (NEW  NEWVALUE) 

(IF  (NOT  (MEMBER  NEW  OLDVALUE))  (ADD. VALUE  UNIT  ’SUB-ELEMENT  NEW))) 
(DOLIST  (OLD  OLDVALUE) 

(IF  (NOT  (MEMBER  OLD  NEWVALUE)) 

(REMOVE. VALUE  UNIT  'SUB-ELEMENT  OLD);) 

NEWVALUE) 
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a  a 


---av-.v 1 


'u  .V.W  .■.VjV.L'.lV. 


kncMiedoe  Base:  FGM-GRAMHAR-KB 


Contents: 


AMY-TYPE-INPUT 
BOOLEAN-INPUT 
BOOLEAN-OUTPUT 
C-BOOLEAN- INPUT 
CONSTANT-INPUT 
FGN-OATA-TOKEN- TYPE 
F6N-6RAMMAR 
FGN-IN-PIN 
FGN-OUT-P IN 

INPUT-DETERIf  INES-OUTPUT 

MATRIX 

T.2D 

T.2X2 

T.3D 

T.3X3 

T .  4D 

T.4X3 

T.4X4 

T. BOOLEAN 

T. CHARACTER 

T. INTEGER 

T.REAL 

T. STRING 

VECTOR 
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Unit:  ftNV-1 VPE-IMPUT 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  BOOLEAN-INPUT 
Meabers:  NIL 
Subclasses:  NIL 

neaber  slot:  LEGAL-DATA-TOKENS 
Valuedass:  NIL 
Values:  (T. BOOLEAN) 


Unit:  BOOLEAN-OUTPUT 
Members:  NIL 
Subclasses:  NIL 

rteaber  slot:  LEGAL-DATA-TOKENS 
Valuedass:  NIL 
Values;  IT. BOOLEAN) 


Unit:  C-BOOLEM- INPUT 
Meabers:  NIL 
Subclasses;  NIL 


Unit:  CONSTANT-INPUT 
Meabers:  NIL 

Subclasses:  UUmt  (C-BQOLEAN-IMPUT  F6N-GRAHMAR-KB) ) 


Unit:  FSN-DATA-TOKEN-TyPE 

Members:  (lUmt  (T. STRING  FGN-GRAMMAR-KB)  *Unit  < T ■  REAL  FGN-GRAMMAR-KB) 

lUnit  (T. INTEGER  FGN-GRAMMAR-KB) 

(Unit  IT. CHARACTER  FGN-GRAMMAR-KB' 
tUnit  IT. BOOLEAN  FGN-GRAMMAR-KB)) 

Subclasses;  (tUnit  (VECTOR  FGN-GRAMMAR-KB)  lUmt  (MATRIX  FGN-GRAMMAR-KB)) 


Unit:  FGN-6RAMNAR 
Meabers:  NIL 
Subclasses:  NIL 
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0«n  slot:  PRIMI TIVE-LIBRARV 
Valuedass:  NIL 

Values;  ( FBM-PR I H I T I VE-L I BRARY ) 


Unit:  F6N-1N-PIN 
Members:  NIL 

Subclasses:  (lUnit  (CONSTANT-INPUT  FSN-GRAHHAR-KBl  #Unit  (BOOLEAN- INPUT  FGN-GRAMNAR-KB) 

♦Unit  (ANY-TYPE-INPUT  FGN-6RAKHAR-KB) ) 


Unit:  FSN-OUT-P IN 
Meabers:  NIL 

Subclasses:  (lUnit  (BOOLEAN-OUTPUT  FSN-GRAMHAR-KB) 
♦Unit  (INPUT-DETERNINES-QUTPUT  FGN-6RAHMAR-KB)  i 


Unit:  INPUT-DETERN1NES-OUTPUT 
Meabers:  NIL 
Subclasses;  NIL 


Unit:  MATRIX 

Meabers!  UlUnit  (T.4X4  FGN-GRAMHAR-RB)  »Umt  (T.4X3  FGN-GRAKMAR-KB) 

f Uni t  (T.3X3  FSN-GRAMHAR-KB) 

♦Unit  (T.2X2  FGN-GRANMAR-KB) I 

Subclasses:  NIL 


Unit:  T.2D 
Members:  NIL 
Subclasses:  NIL 


Unit:  T.2X2 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  T . 3D 
Members:  NIL 
Subclasses!  NIL 


Unit:  T. 3X3 
Members:  NIL 
Subclasses;  NIL 


Unit:  T.4D 
Members:  NIL 
Subclasses;  NIL 


Unit:  T.4X3 
Members;  NIL 
Subclasses:  NIL 


Unit:  T.4X4 
Members:  NIL 
Subclasses;  NIL 


Unit:  I. BOOLEAN 
Members:  NIL 
Subclasses:  NIL 


Unit:  T. CHARACTER 
Members:  NIL 
Subclasses:  NIL 


Unit:  T. INTEGER 
Members:  NIL 
Subclasses;  NIL 


Unit:  T.REAL 
Members:  NIL 
Subclasses;  NIL 
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Knowledge  Base;  FGN-PR IHI T I VE-L IBRARY-KB 


Contents: 

ARI THHET IC-AND-LOQ ICAL 
BUT TONS IN 

CHARACTER-TRANSFORMATION 
CLEAR. LABELS 
COMPARISON 
CURSOR 

DATA-CQNVERSION 

DATA-SELECT I ON-AND-MANI PULA  1 1 ON 
DIALS 

DISPLAY-TREE 

DLABEL.1-8 

DTREE 

F. ACCUMULATE 

F.ADO 

F.ADDC 

F.AND 

F.ATSCALE 

F. AVERAGE 

F.  BOOLE AN. CHOOSE 

F.BROUTE 

F.BROUTEC 

F.CBROUTE 

F.CCONCATENATE 

F.CDIV 

F.CELING 

F.C6T 

F.CHARCONVERT 

F.CHARMASK 

F.CLCSECONDS 

F.CLE 

F.CLFRAMES 
F.CLT 
F. CLUCKS 
F.CMUL 
F. COLOR 
F.  COMP. STRING 
F. CONCATENATE 
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»>  * 


F.NOT 

F.OR 

F.ORC 

F, PARTS 

F.PASSTHRU 

F.PICKINFQ 

F. POSITION. LINE 

F. PRINT 

F.PUT.STR1N6 

F. RANGE. SELECT 

F.  ROUND 

F. ROUTE 

F.ROUTEC 

F. SCALE 

F.SINCOS 

F, SPLIT 

F.SBRQOT 

F.  STRING. TO.NUN 

F ,  SUB 

F.SUBC 

F.SYNC 

F. TAKE. STRING 
F.TINEOUT 
F. TRANS. STRING 
F.VEC 

F.VEC. EX  TRACT 

F.VECC 

F. WINDOW 

F.XFORNDATA 

F.XOR 

F.XORC 

F.XROTATE 

F.XVECTOR 

F.YRQTATE 

F .  Y VECTOR 

F.  ZROTATE 

F.ZVECTOR 

FFPLOT 

FGN-PR I H I T I VE- L I BRARY 
FKEYS 

FLABEL. 1-12 

FLABELU 

FUNCTION-NODE 

HCPIP 

HOSTOUT 

INI T IAL-S1 RUCTURES 

INPUT-FUNCTIONS 

KEYBOARD 

NISCELLANEOUS-FUNCTIONS 
OBJECT- TRANSFORHAT ION 
OFFBUTTONLIGHTS 
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OUTPUT-FUNCTIONS 

PICK 

PICK. LOCATION 

ROBOT-ARM 

SPECKEYS 

TABLET IN 

TABLETOUT 

TIMING 

VIEW-TRANSFORMATION 


Unit:  AR I THMET I C-AND-L06 I CAL 
Members:  <«Unit  (F.XORC  FGN-PRIMITIVE-LIBRARY-KB) 
#Uni  t  (F.XOR  FBN-PRIBI TI VE-LIBRARY-KB) 

♦Unit  (F.SUBC  FGN-PRIMITIVE-LIBRARY-KB) 
lUnit  (F.SUB  FGN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.SQROQT  FGN-PRIMITIVE-LIBRARY-KB) 
lUnit  <F . SINCOS  FGN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F. ROUND  FBN-PRIMITI VE-LIBRARV-KB) 

♦Unit  IF.ORC  FBN-PRIMITI VE-LIBRARY-KB) 

♦Unit  (F.OR  FBN-PRIMITI VE-LIBRARY-KB) 
lUnit  (F. NOT  FGN-PRIMITIVE-LIBRARY-KB) 
lUnit  (F.flULC  FGN-PRIMITIVE-LIBRARY-KB) 
lUnit  (F.MUL  FGN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.HODC  FBN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.HOD  F6N-PR I M I T I VE -L I BRAR Y -KB ) 

♦Unit  iF.DIV  FGN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.DIFC  FGN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.CSUB  FGN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.CHUL  FBN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.CDIV  FGN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.AVERA6E  F6N-PR I M I T I VE -L 1 BRAR Y-KB ) 
♦Unit  (F.AND  FGN-PRIMITIVE-LIBRARY-KB) 

♦Unit  (F.ADDC  FGN-PR IMITIVE-LI BRAR Y -KB ) 

♦Unit  (F.ADD  FBN-PRIMITIVE-LIBRARY-KB) 

♦Unit  <F. ACCUMULATE  FBN-PRIMITIVE-LIBRARY-KB) ) 
Subclasses:  NIL 


Unit:  BUTTONSIN 
Meabers:  NIL 
Subclasses:  NIL 
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Unit!  CHARACTER- TRANSF0RI1A1 ION 
Heibers:  (IUnit  (F.CSCALE  F6N-PRIMI TIVE-LIBRARV-KB) 
lUnit  (F.CROTATE  F6N-PR1HITI VE-LIBRARV-KB) ) 
Subclasses:  NIL 


Unit:  CLEAR. LABELS 
Heibers:  NIL 
Subclasses:  NIL 


Unit:  COMPARISON 

Meibers:  llUmt  (F.NEC  F6N-PR IMI TI VE-L 1BRARV-KB; 
IUnit  (F.NE  FSN-PRiMI TIVE-LIBRARY-KB) 

IUnit  (F.LTC  FGN-PR JHI TI VE-L I BRARY-KB ) 

IUnit  (F.LT  F6N-PRIMI TIVE-LIBRARY-KB ) 

IUnit  (F.LEC  F6H-PR I H I T I VE-L I BRAR Y-KB ) 

♦Unit  (F.LE  F6N-PRIMI T I VE-LIBRARY-KB) 

♦Unit  (F.8TC  FBN-PRIMITIVE-LIBRARV-KB) 

♦Unit  (F.GT  F6N-PRIMI TIVE-LIBRARY-KB) 

IUnit  (F.GEC  F6N-PRIMIT I VE-LIBRARY-KBJ 
♦Unit  (F.GE  FGN-PRIHI TIVE-LIBRARY-KB) 

♦Unit  IF.GCE  FGM-PRIMIT IVE-LIBRARS'-KB) 

♦Unit  (F.EQC  FGN-PRIHI TIVE-LIBRARY-KB) 

♦Unit  !F.EQ  FGN-PRIHIT1VE-LI BRAR Y -KB ) 

♦Unit  (F.COHP. STRING  FGN-PRI tt I T I VE-L I BRARY -KB ) 
♦Unit  (F.CLT  FGN-PRIHI T I VE-L I BRARY-KB) 

♦Unit  (F.CLE  FGN-PRIHI TIVE-LIBRARY-KB) 

♦Unit  (F.CGT  FGN-PRIHI TI VE-L IBRARY-KB) ) 

Subclasses:  NIL 


Unit:  CURSOR 
Heibers:  NIL 
Subclasses:  NIL 


Unit:  DATA-CGNVERSIQN 

Heibers:  (IUnit  tF.ZVECTQR  FGN-PR1HITI VE-L IBRARY-KB) 
♦Unit  (F.YVECTOR  FGN-PRIHI TIVE-LIBRARY-KB) 

♦Unit  (F.XVECTOR  FGN-FRIHITIVE-L3BRARY-KB) 

♦Unit  (F.XFORMDATA  F6N-PRIHI TIVE-LIBRARY-KB) 

♦Unit  (F.VECC  FGN-PR IHITIVE-LIBRARY-KB) 

•Unit  (F.VEC  FGN-PR IHITIVE-LIBRARY-KB) 


•Unit  IF, TRANS. STRING  FSN-PRIHI TI VE-LI BRARY-K8 ) 
•Unit  IF.STRIN6.TQ.NUH  FGN-PRIHITIVE-LIBRARY-KB) 
•Unit  (F. PRINT  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F, PARTS  F6N-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.HATRIX4  F6N-PR I«I T 1 VE-L I BRAR Y -KB) 

•Unit  (F.NATRIX3  F6N-PRI H I T I VE-L I BRAR Y-KB ) 

•Unit  (F.HATRIX2  F6N-PRIM1T1VE-LIBRARY-K.8) 

•Unit  (F. FLOAT  F6N-PRIM1T1VE-LIBRARY-K8! 

•Unit  (F.FIX  FGN-PRIH1TI VE-LIBRARY-KB) 

•Unit  (F.CVEC  F6M-PR I H I T I VE-L I BRAR V -KB ) 

•Unit  (F.CHARCONVERT  FGN-PR I MI T I VE-L I BRAR  Y-KB ) 
•Unit  (F.CELING  F6N-PRIHITIVE-LIBRARY-K8!) 

Subclasses:  NIL 


Unit:  DAT A-SELEC T I ON-AND-NAN IPULAT I ON 
Heabersl  llllnit  (F.VEC. EXTRACT  FGN-PRIHITIVE-LIBRARY-KB) 
•Unit  (F. TAKE. STRING  FSN-PRIHI TI VE-LIBRARY-KB! 

•Unit  (F. SPLIT  F6N-PRIH1TIVE-LIBRARY-K8) 

•Unit  (F.ROUTEC  FSN-PRIHI TI VE-LIBRARY-KB) 

•Unit  IF. ROUTE  FGN-PRJHIT1 VE-LIBRARY-KB) 

•Unit  (F.RAN6E. SELECT  FSN-PRIHITIVE-LIBRARV-KB) 

•Unit  (F, PUT. STRING  FGN-PRIH1TIVE-LIBRARY-K8) 

•Unit  (F.PASSTHRU  F6N-PRIHITIVE-LIBRARY-K8) 

•Unit  (F.HCONCATENATE  FGN-PRIMITI VE-L IBRARV-KB) 

•Unit  (F.LINEEOITOR  FSN-PRIHI T I VE-L I BRARY-K8 / 

•Unit  (F. LIMIT  F  GN-PR IHI T I  VE-L  I  BRAR  Y-K.B) 

•Unit  (F.LEN6HT. STRING  F6N-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.LBL. EXTRACT  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  <F. LABEL  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F. INPUTS, CHOOSE  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F. GATHER. STRING  FGN-PRIHITIVE-LIBRARY-KB! 

•Unit  (F.FINC. STRING  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.DELETA  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.CROUTE  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F. CONSTANT  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.CONCATENTATEC  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  IF. CONCATENATE  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.CHARMASK  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.CCONCATENATE  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  IF.CBROUTE  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.BROUTEC  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.BROUTE  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  IF. BOOLEAN. CHOOSE  FGN-PRIHITIVE-LIBRARY-KB) 
•Unit  IF. AT SCALE  FGN-PRIHITIVE-LIBRARY-KB)) 
Subclasses;  NIL 


Unit:  DIALS 
Members;  NIL 
Subclasses:  NIL 


Unit:  DISPLAY-TREE 

Members!  <#Unit  (ROBOT-ARM  F6N-PR I MI TI VE-L I BRAR Y -KB ) 
lUnit  (CTREE  FGN-PRIMITIVE-LIBRARY-KB) ) 
Subclasses:  NIL 


Unit:  DLABEL.l-fl 
Menbers;  NIL 
Subclasses:  NIL 


Unit:  CTREE 
Members:  NIL 
Subclasses:  NIL 


Unit:  F. ACCUMULATE 
Members!  NIL 
Subclasses:  NIL 


Unit:  F.ADD 
Members!  NIL 
Subclasses:  NIL 


Unit:  F.ADDC 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.AND 
Members;  NIL 
Subclasses:  NIL 
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Unit:  f. A [SCALE 
Keabers:  NIL 
Subclasses:  NIL 


Unit:  F. AVERAGE 
fleabers:  NIL 
Subclasses:  NIL 


Unit:  F. BOOLEAN. CHOOSE 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F.BRQUIE 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F.BROUTEC 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F.C8RQUTE 
Neabers!  NIL 
Subclasses:  NIL 


Unit:  F.CCONCATENATE 
Neabers;  NIL 
Subclasses:  NIL 


Unit:  F.CDIV 
Neabers:  NIL 
Subclasses;  NIL 
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unit;  F. CLUCKS 
Members:  MIL 
Subclasses;  NIL 


Unit:  F.CMUL 
Members*.  NIL 
Subclasses;  NIL 


Unit:  F. COLOR 
Members:  NIL 
Subclasses:  NIL 


Unit:  F. COMP. STRING 
Members:  NIL 
Subclasses:  NIL 


Unit:  F. CONCATENATE 
Members!  NIL 
Subclasses;  NIL 


Unit:  F.CONCATENTATEC 
Members:  NIL 
Subclasses;  NIL 


Unit:  F. CONSTANT 
Members:  NIL 
Subclasses:  NIL 

Member  slot:  INITIAL-SUB-ELEMENT 
Valuedass:  NIL 

Values!  i <01  tUmt  ( INPUT -DETERMINES-OUTF'UT  FGN-GRAMHAR-KB)  SUB-QUIPUT) 
(12  lUnit  (ANY-TYPE-INPUT  FGN-SRAMMAR-KB)  SUB-INPUT) 

(II  lUnit  (ANY-TYPE-INPUT  FBN-GRAMMAR-KB)  SUB-INPUT)) 


Member  slot;  LABEL 
Valueclass;  NIL 
Values:  ("f iconstant") 


'init:  F.CROTrtiE 
Members!  NIL 
Subclasses;  NIL 


Unit:  F.CRQUTE 
Members:  NIL 
Subclasses;  NIL 


Unit:  F.CSCALE 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.CSUB 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.CVEC 
Members!  NIL 
Subclasses:  NIL 


Unit:  F.OELETA 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.DIFC 
Members:  NIL 
Subclasses:  NIL 


Unit;  F.DI 


Unit:  F.GEC 
Members;  NIL 
Subclasses;  NIL 


Unit:  F.GT 
Members’.  NIL 
Subclasses:  NIL 


Unit:  F.GTC 
Members:  NIL 
Subclasses:  NIL 


Unit;  F, INPUTS. CHOOSE 
Members:  NIL 
Subclasses:  NIL 


Unit:  F. LABEL 
Members:  NIL 
Subclasses:  NIL 


Unit:  F. LBL. EXTRACT 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.LE 
Members!  NIL 
Subclasses:  NIL 


Unit:  F.LEC 
Members:  NIL 
Subclasses;  NIL 
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Unit:  F.LENGHT. STRING 
Members:  NIL 
Subclasses:  NIL 


Unit:  F. LIMIT 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.LINEEDITOR 
Members:  NIL 
Subclasses:  NIL 


Unit;  KLCCUT 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.LBOkFPON 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.LT 
Members'.  NIL 
Subclasses:  NIL 


Unit:  F.LTC 
Members'.  NIL 
Subclasses:  N 


Unit:  F.MA1FH.H2 
Members!  NIL 
Subclasses:  N 


Unit:  F.flMRIt; 
deabers:  NIL 
Subclasses*  NIL 


yi.1t:  F.MAIPlXi 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  MOICftTENAJE 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.dOD 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.HODC 
Members:  NIL 
Subclasses;  NIu 


Unit:  f.kul 
Member s ;  NIL 
Subclasses:  NIL 


Umt:  f.mul: 

Menber  = ;  NIL 
Subclasses:  NIL 


Unit:  F.NE 
Members:  NIL 
Subclasses:  NIL 
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Unit:  F.NtC 
Members;  NIL 
Subclasses:  NIL 


Unit:  F.NOP 
Members:  NIL 
Subclasses:  NIL 


Unit:  F .HOT 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.CF. 
Members:  NIL 
Subclasses:  NIL 


Unit:  F , URL 
Members:  NIL 
Subclasses;  NIL 


Unit:  F, PARIS 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.PfiSSTHRU 
Members:  NIL 
Subclasses:  NIL 


Unit:  F.PICKINFG 
Members:  NIL 
Subclasses:  NIL 


Unit:  F, POSITION. LINE 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F. PRINT 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F, PUT. STRING 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F. RANGE. SELECT 
Neabers!  NIL 
Subclasses:  NIL 


Unit:  F. ROUND 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F. ROUTE 
Neabers;  NIL 
Subclasses;  NIL 


Unit:  F.ROUTEC 
Neabers!  NIL 
Subclasses:  NIL 


Unit:  F. SCALE 
Neabers:  NIL 
Subclasses:  NIL 


119 


Unit:  F.3INC0S 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F. SPLIT 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F.SQROOT 
Heabers:  NIL 
Subclasses:  NIL 


Unit:  F. STRING. TO. NUN 
Heaters:  NIL 
Subclasses:  NIL 


Unit:  F.SUB 
Heabers:  NIL 
Subclasses:  NIL 


Unit:  F.SUBC 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F.SVNC 
Neabers:  NIL 
Subclasses:  NIL 


Unit:  F. TAKE. STRING 
Neabers:  NIL 
Subclasses:  NIL 


Unit;  F. TIMEOUT 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  F. TRANS, STRING 
Members:  NIL 
Subclasses;  NIL 


Unit:  F.VEC 
Meitoers;  NIL 
Subclasses:  NIL 


Unit:  F.VEC. EXTRACT 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  F.VECC 
Members:  NIL 
Subclasses:  NIL 


Unit:  F. WINDOW 
Meabers:  NIL 
Subclasses:  NIL 


Unit!  F.XFORMOATA 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  F.XOR 
Meabers!  NIL 
Subclasses:  NIL 


Unit:  F.ZRQTATE 
Meabers!  N2L 
Subclasses:  NIL 


Unit:  F.ZVECTOR 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  FFPLOT 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  FGN-PRIMI TIVE-LIBR ARY 
Meabers:  NIL 

Subclasses:  (IUnit  (DISPLAY-TREE  FGN-PRIN1TIVE-LI8RARY-LB) 

♦Unit  (FUNCTION-NODE  FGN-PRIMI T I VE-LIBRARV-KB) / 

Meaber  slot:  MEMBER-MENU 
Valuedass:  NIL 
Values:  ((FUNCTION-NODE 

♦Unit  (FUNCTION-NODE  FGN-PRII1ITIVE-LIBfiARH<F) 

'See  sub  aenu" 

(SUBITEMS 

(AR1THMETIC-AND-L0GICAL 

♦Unit  (ARITHMETIC-AND-LOGICAL  FGN-PRIMITIVE-LIBPARY-KB) 

“See  sub  aenu" 

(SUBITEMS  C'F.XOR"  iUnit  (F.XQR  FGN-PR1NITIVE-LI8RARY-K8) 

■Instantiate  F.XOR'l 

("F. ACCUMULATE"  IUnit  (F. ACCUMULATE  F6M-PRIBITIVE-LIBRARV-KB) 
"Instantiate  F, ACCUMULATE') 

I'F.ADD"  IUnit  (F.ADD  FGN-PRIMITI VE-LIBRARY-kB) 

"Instantiate  F.ADD') 

CF.ADDC"  IUnit  (F.ADDC  FGN-PRIMI TIVE-LI8RARY-KB) 

"Instantiate  F.ADDC') 

CF.AND'  IUnit  (F.AND  FGN-PR I M I T I VE- L I BRAR Y -KB ) 

'Instantiate  F.AND*) 

!"F. AVERAGE'  IUnit  (F. AVERAGE  FGN-PP I  MI T I VE-L IBRARY-KB) 
■Instantiate  F. AVERAGE’ I 

CF.CDIV"  IUnit  (F.CDIV  FGN-PRIMI TIVE-LIBRARY-KB) 

'Instantiate  F.CDIV'! 

"F.CMUL*  IUnit  (F.CMUL  FGN-PRIMITIVE-LIBRARY-KB) 


"Instantiate  F.CHUL") 

CF.CSUB*  lUmt  (F.CSUS  FGN-PR IMI T I VE-L I BRAR V -K&) 
"Instantiate  F.CSUB"! 

("F.DIV"  lUnit  (F.DIV  FGN-FR1MITI VE-LIBRARV-KB) 
■Instantiate  F.DIV! 

("F.DIFC*  llinit  (F.DIFC  FGN-PR1MI T IVE-L 1 BRAP: V -KB > 
■Instantiate  F.DIFC") 

("F.MOD"  lUnit  (F . MOD  FGN-PRIM1TIVE-LIBRARY-KB) 
"Instantiate  F.HQD") 

("F.MQDC"  lUnit  (F.HODC  F  GN-PR I  (1 1 T I  VE-L  I  BRAR  Y  -  KB ) 
■Instantiate  F.MQDC") 

("F.MUL"  lUnit  (F.MUL  FGN-PRIH1TIVE-LIBRARY-KB) 
■Instantiate  F.HUL’) 

CF.HULC*  lUnit  (F.MULC  FGN-PR I M I T I VE-L 1 BRAR V -KB ) 
•Instantiate  F.MULC") 

( "F.NQT"  lUnit  (F.NOT  FGN-PRIMITI VE-L IBRAFY-KB) 
■Instantiate  F.NQT*) 

CF.OR"  lUnit  IF, OR  FGN-PRIttJ  T I  VE-L  JBRARV-KB) 
"Instantiate  F.QR"! 

CF.QRC"  lUnit  (F.QRC  FGN-PRIMIT I VE-L IBRARY-KB) 
'Instantiate  F.QRC") 

(*F. ROUND"  lUnit  (F. ROUND  FGN-PRIHI TI VE-LIBRARY-KB) 
■Instantiate  F. ROUND') 

( ’F.SINCOS*  lUnit  (F.SINCOS  FGN-PRIttI TI VE-LI BRARY-KB) 
"Instantiate  F.SINCOS") 

(’F.SQROOT’  lUnit  (F.S8R00T  FGN-PRIMITIVE-LIBRARY-KB) 
•Instantiate  F.SQROOI") 

CF.SUB*  lUnit  (F.SUB  FGN-PRINIT I VE-LIBRARY-KB) 
■Instantiate  F.SUB") 

CF.SUBC"  lUnit  (F.SUBC  FGN-PR I MI T I VE-L I BRAR Y - KB ) 
"Instantiate  F.SUBC"' 

CF.JQRC"  lUnit  (F.YQRC  FGN-PR JMITIVE-LIERARY-KB) 
■Instantiate  F.XQRC’))) 

(CHARACTER-TRANSFCRNATION 

•Unit  (CHARACTER-TRANSFORMATION  FGN-PRIMITI VE-LIBRARY-KB) 

'See  sub  nenu" 

(SUBITEMS  < "F. CROTATE"  lUnit  (F.CROTATE  FGN-PRIMITI VE-LIBRARY-KB' 
"Instantiate  F.CROTATE") 

< 'F.CSCALE'  lUnit  (F.CSCALE  F6N-PRIMJTIVE-L1BRARY-K8) 
"Instantiate  F.CSCALE"))) 

(COMPARISON 

•Unit  (COMPARISON  FGN-PRIMI T I VE-LIBRARY-KB) 

'See  sub  «enu" 

(SUBITEMS  ( "F.GCE"  lUnit  (F.GCE  FGN-PRIMI T I VE-LIBRARY-KB > 
"Instantiate  F.GCE") 

("F.CGT"  lUnit  (F.CG1  FGN-PRIMI TI VE-L IBRARY -KB ) 
•Instantiate  F.CGT") 

("F.CLE"  lUnit  (F.CLE  FGN-PRIMITI VE-LIBRARY-KB) 
■Instantiate  F.CLE"' 

( ’F.CLT"  lUnit  (F.CLT  FGN-PRIMITI VE-LIBRARY-KB) 
"Instantiate  F.CLT"! 


i"F. COMP. STRING"  lUnit  (F. COMP. STRING  FGN-PRIMITIVE-LIBRARV-KB) 
"Instantiate  F. COMP. STRING"! 

("F.EQ"  lUnit  (F.EQ  FGN-PRIMI TIVE-LIBRARV-KB) 

''Instantiate  F.EQ*) 

CF.EQC"  lUnit  (F.EQC  FGN-PR1MI11VE-L1BRARY-KB) 
a Instantiate  F.EQC") 

t’F.GE"  lUnit  (F.GE  FGN-PRIMI T IVE-LIBRARV-K6) 

“Instantiate  F.8E‘) 

CF.GEC"  lUnit  (F.GEC  F6M-PRIHI1 IVE-LIBfiARY-KB) 

"instantiate  F.GEC) 

CF.GT"  lUnit  (F.GT  FGN-PRIMI  TIVE-LIBRARV-KB) 

"Instantiate  F.GT") 

("F.6TC"  lUnit  iF.GTC  FGN-PRIMITI VE-L I&RARY-RB) 

“Instantiate  F.GTC") 

("F.LE"  lUnit  (F.LE  FGN-PRlMITIVE-LIBRARi-KB) 

"Instantiate  F.LE“i 

i'F.LEC"  lUnit  (F.LEC  F GN-PR I M I T IVE-L I Bfi AF  Y -KB ! 

"Instantiate  F.LEC") 

CF.LT*  lUnit  !F.LT  FGN-PRIMI TIVE-LIBRARY-KS) 

"Instantiate  F.Lf*> 

t'F.LIC"  lUnit  (F.LTC  FGN-PRIMIT  IVE-LIBfiARY-KB) 

■Instantiate  F.LTC") 

("F.NE"  lUnit  (F.NE  FGN-PRIMIT IVE-LIBPARY-V.B) 

"Instantiate  F.NE") 

("F.NEC"  lUnit  <F. NEC  FGN-PRJH1T IVE-L I BRARY-KB) 

"Instantiate  F.NEC*))) 

(DATA-CONVERSION 

♦Unit  (DATA-CONVERSION  FGN-PSINITIVE -LIBRARY -KB) 

"See  sub  senu" 

(SUBITEMS 

("F.CELING"  lUnit  (F.CELING  FGN-PRIMITIVE-L JBRARY-KB) 

“Instantiate  F.CELING”) 

("F.CHARCONVERT"  lUnit  (F.CHARCONVERT  FGN-PR I MI T I VE-L I BRARY-K B ) 
"Instantiate  F.CHARCONVERT") 

("F.CVEC"  lUnit  (F.CVEC  FGN-PRIMI T IVE-LIBRAR Y-KB)  "Instantiate  F.CVEC"! 
("F.FIX"  lUnit  tF.FIX  FGN-PR IMI T I VE-L I BRARY-KB)  "Instantiate  F.FIX") 

("F. FLOAT"  lUnit  (F, FLOAT  FGN-PRIMI TIVE-LI BRARY-KB) 

•Instantiate  F. FLOAT") 

("F.MATRIX2"  lUnit  (F.MATRIX2  FGN-PRIMIT I VE-L IBRARY-KB ) 

"Instantiate  F.MATR1X2") 

(*F.MAfRIX3*  lUnit  (F.MATRIX3  FGN-PRIMI fIVE-LIBRARY-KB) 

"Instantiate  F.MATRIX3") 

("F.MATRIX4*  lUnit  (F. MATRIX!  FGN-PRIMIT I VE-LIBRARY -KB < 

"Instantiate  F.MATRIX4") 

("F. PARIS"  lUnit  (F. PARTS  FGN-PR I  MI T I VE-L I BRAR ( -LB) 

"Instantiate  F. PARTS") 

(“F. PRINT’  lUnit  (F. PRINT  FGN-PRIMI TI VE-L IBRARY -KB > 

“Instantiate  F. PRINT") 

("F. STRING. TO. NUM"  lUnit  (F, STRING. TO. HUM  FGN-FR I M I T I VE-L I BRAR Y -KB • 
"Instantiate  F. STRING, TO. NUM") 

("F. TRANS. STRING"  lUnit  (F. TRANS. STRING  FGN-PR I  MIT  I VE-L i BRAR ( -KB > 


'Instantiate  F. TRANS. STRING") 

("F.VEC"  IUnit  (F.VEC  FGN-PRIHIT I VE-LI BRARV-KB)  "Instantiate  F.VEC", 
CF.VECC"  iUnit  (F.VECC  FGN-PRIMI T I VE-L IBRARV-KBj  "Instantiate  F.VECC* 
i*F. XFORMOATA"  »Umt  ( F. XFORMDATA  FGN-PRIMIT IVE-LIBRARV-KBi 
“Instantiate  F, XFQRHDATA" ) 

CF.XVECTOR"  IUnit  (F, XVECTQR  FGN-PRIMIT  I VE-L  IBRARv-KB> 

■Instantiate  F.XVECTOR") 

("F.YVECTQR"  #Unit  (F.YVECTQR  FGN-PRIMIT I VE-U &RARv-kB ) 

"Instantiate  F.YVECTQR") 

("F.ZVECTGR*  IUnit  (F.2VEC-TQR  FGN-PRIMI flVE-LIBRARY-KB) 

"Instantiate  F.ZVECTOR"))) 

( DATA-SELECT 10N-AMD-MANIPULATIQN 

IUnit  ( DAT A-SELEC 1 1 QN-ANB-MANI PULAT I  ON  F6N-PR1MITI VE-LIBRARY-KB) 

“See  sub  *enu" 

(SUBITEMS 

("F. INPUTS. CHOOSE"  IUnit  (F.INPU1S, CHOOSE  FGN-PRIMIT  1  t'E-LIBRARY -KB ) 
•Instantiate  F. INPUTS. CHOOSE") 

( " F , ATSCALE"  IUnit  IF.ATSCALE  FGN-PRIMI T1VE-L IBRARY-KD) 

"Instantiate  F. ATSCALE") 

(“F. BOOLEAN. CHOOSE"  IUnit  (F. BOOLEAN. CHOOSE  FGN-PRIMIT IVE-LIBRARY-KB) 
■Instantiate  F. BOOLEAN. CHOOSE" ) 

! "F. BROUTE"  IUnit  (F.BROUTE  FGN-PRIMIT I VE-LI BRARY-KB) 

"Instantiate  F.BROUTE"! 

("F.BROU1EC"  IUnit  IF.BROUTEC  FGN-PRIMIT IVE-LIBRARY-KB) 

"Instantiate  F.BROUTEC’! 

("F.CBROUTE"  IUnit  (F.CBROUTE  F6N-PRJ  MI TIVE-L1 EFAfi Y -KB ) 

"Instantiate  F.CBROUTE") 

("F.CCONCATENATE"  IUnit  (F.CCONCATENATE  FGN-PRIMITIVE-LIBRARY-KB) 
"Instantiate  F.CCONCATENATE") 

("F.CHARMASK"  IUnit  (F.CHARMASK  FGN-PRIMIT IVE-LIBRARY-KB) 

"Instantiate  F.CHARMASK") 

("F, CONCATENATE"  IUnit  (F. CONCATENATE  FGN-PRIMITIVE-LIBRARY-KB) 
"Instantiate  F. CONCATENATE") 

("F.CONCATENTATEC"  IUnit  IF.CONCATENTATEC  FGN-PRIMITIVE-LIBRARY-KB/ 
"Instantiate  F.CONCATENTATEC") 

CF, CONSTANT"  IUnit  (F. CONSTANT  FGN-PRIMITIVE-LIBRARY-KB) 

"Instantiate  F. CONSTANT") 

("F.CROUTE"  IUnit  IF.CROUTE  FGN-PRIMITIVE-LIBRARY-KB! 

"Instantiate  F.CROUTE') 

("F.DELETA"  IUnit  (F.DELETA  FGN-PRIMITIVE-LIBRARY-KB) 

"Instantiate  F.DELETA") 

( "F, F INC- STRING"  IUnit  (F.FINC. STRING  FGN-PRIMIT IVE-LIBRARY-KB) 
"Instantiate  F.FINC. STRING’) 

CF. GATHER. STRING"  IUnit  (F. GATHER. STRING  FGN-PRIMITIVE-LIBRARY-KB; 

•Instantiate  F, GATHER. STRING") 

CF, LABEL"  IUnit  IF. LABEL  FGN-PRIMITIVE-LIBRARY-KB) 

"Instantiate  F. LABEL") 

CF.L8L. EXTRACT"  IUnit  (F.LBL. EXTRACT  FGN-PRIMITIVE-LIBRARY-KB) 
"Instantiate  F.LBL. EXTRACT") 

CF.LENGHI. STRING"  IUnit  (F.LENGHT. STRING  FGN-PRIMITIVE-LIBRARY-KB) 
■Instantiate  F.LEN6HT. STRING") 
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i"F. LIMIT"  fUnit  (F. LIMIT  FGN-PRIMITI VE-L IBRARV-KB) 

’Instantiate  F. LIMIT’) 

r.  "F.  L I NEEDITOR M  lUmt  IF.LINEEOITOR  FGH-PR IMI TIVE-L I BRARY-KB i 
‘Instantiate  F.LINEEDITQR’) 

("F.MCGNCATENATE'  #Umt  IF.MCONCATENATE  FGN-PRIMI TIVE-L I BRARY-KB) 
’Instantiate  F.MCQNCATENATE') 

( •F.PASSTHRU"  lUnit  iF.PASSTHRU  FGN-PR  1(117 1 VE-L IBRAftV -KB) 

“Instantiate  F.PASSTHRU’) 

(“F. PUT. STRING"  lUmt  (F. PUT. STRING  FGN-PR 1MI T 1 VE-L IBRARV-kB) 

‘Instantiate  F. PUT, STRING') 

!‘F. RANGE. SELECT’  lUnit  (F. RANGE. SELECT  FGN-PR IM1 T I VE-L I BRARY-KB ) 
■Instantiate  F, RANGE. SELECT") 

(“F. ROUTE"  »Umt  (F. ROUTE  FGN-PRIMITIVE-L I  BRARY-KB) 

'Instantiate  F. ROUTE') 

("F.ROUTEC"  lUnit  (F.ROUTEC  FGN-PRIfll TI VE-LI BRARY-KB) 

"Instantiate  F.ROUTEC") 

l”F. SPLIT"  lUnit  (F. SPLIT  FGN-PRIKI TIVE-LIBRARY-PB) 

’Instantiate  F, SPLIT"! 

!  "F.  TARE.  STRING"  lUmt  (F.  TAKE.  STRING  FGN-PR  I  Ml  T  It’E-L  I  BRARY-KS) 
“Instantiate  F. TAKE. STRING') 

\ "F.VEC. EXTRACT”  lUmt  iF.VEC. EXTRACT  FGN-PRIMITIVE-L IBRARr -KB) 
‘Instantiate  F. VEC. EXTRACT") ) 

(MISCELLANEOUS-FUNCTIONS 

(Unit  (MISCELLANEOUS-FUNCTIONS  FGN-PR I M I T I VE -L I BRAR Y -K B ) 

‘See  sub  aenu" 

(SUBITEMS 

!"F. COLOR"  lUnit  IF. COLOR  FGN-PR  INIUVE-LIBR'ARV-KB) 

“Instantiate  F. COLOR’! 

I’F. EDGE. DETECT"  lUnit  IF. EDGE. DETECT  FGH-FRIMIT1VE-L1BRARY-KB) 
’Instantiate  F. EDGE. DETECT’) 

("F.  FETCH"  tUmt  (F. FETCH  FGN-PR  INI  TIVE-LI  BRARY-KB) 

’Instantiate  F.FETCH’) 

;“F.NOP"  lUmt  IF. NOP  FGN-PR  IMIT I  VE -LIBRARY -KB)  ’Instantiate  F.NOP") 
i’F.PICKINFO’  (Unit  IF.PICKINFO  FGN-PRIMITIVE-L I BRARY-KB' 

'Instantiate  F.PICKINFO") 

l 'F. POSITION. LINE'  lUmt  (F. POSITION. LINE  FGN-PRIKITIVE-L1BRARY-KB) 
•Instantiate  F. POSITION, LINE") 

. ’F.SYNC”  lUnit  IF. SYNC  FGN-PRIfll T I VE-L I BPARY-K B )  "Instantiate  F. SYNC'D ) 
( OBJECT -TRANSFORMATION 

#Unit  (OBJECT-TRANSFORMATION  FGN-PRIMITIVE-L IBRARY-KB) 

'See  sub  aenu" 

SUBITEMS  ("F.DSCALE"  lUnit  tF.DSCALE  FGH-FRIMITT. E-LI BRARY-KB; 
'Instantiate  F . OSCALE ' > 

I’F.DXROTATE"  tUmt  (F.DXROTA1E  FGN-FRIMIT!'.E-LI BRARY-KB) 
Instantiate  F. DxROTATE" ■ 

I’F.DYROTATE"  .unit  (F.D'.ROTAIE  FGN-FR1MIY I VE-l I EF-A8 v -K B > 
’Instantiate  F.OYROTATE’’ 

("F.DZROTATE"  lUnit  iF.DZRQThIE  FGM-PRIMJIVE-LIBFARy-KB' 
’Instantiate  F.DZROTATE" > 

■  ’F.  XROTATE"  tUmt  iF.XROTATE  FGN-PRIMITIVE-L  I  BRARi -KB  i 
"Instantiate  F.xROTATE’i 


i  'F, » ROTATE "  lUnit  (F.VRQTATE  FGN-FR I II I T I VE~L I BRAR V- KB > 
"Instantiate  F.VRQTATE"! 

i‘F. ZROTATE"  lUnit  (F . ZROTATE  FGN-PR I M I T I VE-L I BR AR V- KB J 
“Instantiate  F. ZROTATE') 

t"F. SCALE"  lUnit  (F. SCALE  FGN-F'RIHITIVE-LIERARr-KB) 
"Instantiate  F.SCALE*) ) > 

(TIMING 

lUnit  (TIMING  FGN-PRUIlTIVE-LIBRhRi-KB) 

"See  sub  aenu" 

(SUBITEMS  ("F.CLCSECCNQS"  lUnit  (F.CLCSECONCS  FGN-PRIMITIVE-LIBRARV-KB) 
"Instantiate  F.CLCSECONDS") 

("F.CLFRAMES”  lUnit  (F.CLFRAMES  FGH-PRINITIVE-LIBRAF.Y-k'BT 
"Instantiate  F.CLFRAMES') 

i'F. CHICKS"  lUnit  (F.CLTICKS  FGU-F R I rt I T IVE-L I DRi-R Y -I. o ! 
"Instantiate  F.CLTICKS") 

("F. TIMEOUT"  (Unit  IF. TIMEOUT  FGN-PRIMITIVE-LIBRARV-KB) 
"Instantiate  F. TIMEOUT") i ) 

(VIEW-TRANSFORMATION 

lUnit  (VIEW-TRANSFORMATION  FGN-PRIMITIVE-LIBRARv-KB) 

"See  sub  menu' 

(SUBITEMS  (“F.FOV  lUnit  IF.FOV  FGN-PRIM I T I VE-L IBRAR i-kS) 

"Instantiate  F.FOV) 

("F.LQOKAT"  lUnit  (F.LQQKAT  F6N-PRIMI T I VE-LIBRARV-KB) 
"Instantiate  F.LQOKAT”) 

(“F.LOOKFROH”  lUnit  IF.LOQKFRCM  FGN-PRIMITIVE-LIBRARv-KB) 
“Instantiate  F.L00KFR0M') 

(“F. WINDOW"  lUnit  vF. WINDOW  FGN-PRIMITIVE-LIBRARV-KB.) 
"Instantiate  F. WINDOW"))! 

(OUTPUT-FUNCTIONS 

•Unit  (OUTPUT-FUNCTIONS  FGN-PRIMITIVE-LIBRARV-KB) 

"See  sub  aenu" 

(SUBITEMS 

/CLEAR. LABELS"  lUnit  (CLEAR. LABELS  F  GN-PR I  MIT i VE-L I BRAR  r -K Bi 
"Instantiate  CLEAR. LABELS") 

("DLABEL. 1-8"  lUnit  (CLABEL.1-3  F6N-PRIMI 1 1 VE-LIBRARV-KB) 

“Instantiate  DLABEL. 1-8") 

("PFPLOT"  lUnit  (FFPLOT  FGN-FR I M I T IV E-L I BRARV -K B )  "Instantiate  FFPLOT") 
. "FKEVS"  lUnit  IFKEVS  FGN-FRIMI TIVE-LlBRARV-KB)  "Instantiate  FKEtS") 
("FLABEL0"  lUnit  (FLABEL2  FGH-PRIMI TIVE-LIBRARr-KB) 

“Instantiate  FLABELV) 

("FLABEL.  1-12“  lUnit  (FLABEL.  1-12  FGN-PRIMI IIVE-LiBRARcKEn 
"Instantiate  FLABEL, 1-12"! 

CHCPIP-  lUnit  (HCPIP  FGN-PRIMIIIVE-LlBRfiRV-KB)  “Instantiate  HCP1P") 
("HOSTOUT"  lUnit  (HOSTOUT  F  GN-PR I M I II VE -L I BRAR  V -KB ) 

"Instantiate  HOSTOUT"! 

i'OFFBUTIONLIGHTS"  lUnit  iOFFBUTTCNLI 6HTS  FGN-FRIMI TIVE-L IBRAR V -KB' 
"Instantiate  0FFBUTT0NLI5HTS” ) ) ) 

! INPUT-FUNCTIONS 

•Uni t  (INPUT-FUNCTIONS  FGN-PRIMITIVE-LIBRARV-KB) 

"See  sub  aenu" 

(SUBITEMS  ( "BUTTONS  JV  lUnit  IBUTTONSIN  FGN-PR  I M I T 1 VE -L  J  BftfiR  V -KB ) 


128 


"Instantiate  BUMONSiN') 

{“DIALS"  #Unit  (DIALS  FGN-PRIMII I VE-L 1BRARY-KB) 

'Instantiate  DIALS') 

("KEYBOARD"  lUnit  (KEYBOARD  FGN-PRIMIT IVE-L1 BRARY-KBi 
"Instantiate  KEYBOARD") 

('PICK"  lUnit  (PICK  FGN-PR1M1TIVE-LI8RARY-KB) 

■Instantiate  PICK') 

CSPECKEYS"  lUnit  (SPECKEYS  FGN-PRIMITIVE-LIBRARY-KB) 
•Instantiate  SPECKEYS") 

CTA8LETIN"  lUnit  (TABLETIN  FfiN-PRIHITIVE-LI BRARY-FB ■ 
"Instantiate  TABLETIN") 

CTABLETOUT'  lUnit  (TABLETOUT  FBN-PRIMITI VE-L IBRARY-KB) 
■Instantiate  TABLETOUT'))) 

(INITIAL-STRUCTURES 

lUnit  (INITIAL-STRUCTURES  FGM-PRIHIT I VE-LI BRARY-KB) 

"See  sub  aenu" 

(SUBITEMS 

("CURSOR"  lUnit  (CURSOR  FGN-PR 1  MIT  I VE-LI BRARY-KB)  "Instantiate  CURSOR') 
("PICK. LOCATION'  lUnit  (PICK. LOCATION  F5N-PRIKITIVE-LIBRARY-KB) 
"Instantiate  PICK, LOCATION'))))) 

(DISPLAY-TREE 

lUnit  (DISPLAY-TREE  FGN-PR3 MI T I VE-L I BRARY -KB) 

"See  sub  aenu" 

(SUBITEMS  ("DTREE"  lUnit  (DTREE  FGN-PRIMITIVE-LIBRARY-KB) 

"Instantiate  CTREE" i 

(“ROBOT-ARM"  It/nit  (ROBOT -ARM  FGN-PR  1  HI  I]  VE  -L I  BfiAR  V  -KB) 
■instantiate  ROBOT-ARM")))) 


Unit:  FKEYS 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  FLABEL. 1-12 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  FLABELfl 
Meabers:  NIL 
Subclasses:  NIL 


Unit:  FUNCTION-NODE 
Meabers:  NIL 

Subclasses:  (lUnit  ! DATA-SELECT I ON-AND-MANI PULAT I  ON  F6N-FRIMITI VE-LIBRARY-FB) 


•Unit  <  DAT  A-CONVERS I  ON  FGN-PRIMI T I VE-L IBRARY-KB) 

•Unit  (COMPARISON  FGN-PR INI T I VE-L IBRARY-KB) 

•Unit  (CHARACTER- TRANSFORMATION  F6N-PRIMITIVE-LIBRARY-KB) 
•Unit  ( AR I THMET I C-ANB-L06 1  CAL  FSN-PR  1(11  T I  VE-L  I SRARY  -KB ) 
♦Unit  (VIEN-TRANSFORHATION  FGN-PR1MITIVE-LIBRARY-KB) 

♦Unit  (TIMING  FGN-PRIM1TIVE-L1BRARY-KB) 

lUnit  (OUTPUT-FUNCTIONS  FGN-PRIM1 TIVE-LIBRARY-KB) 

(Unit  (OBJECT-TRANSFORMATION  FGN-PRIMI TIVE-LIBRARY-KB) 
•Unit  (MISCELLANEOUS-FUNCTIONS  F6N-PRIHITIVE-LIBRARY-KB) 
♦Unit  (INPUT-FUNCTIONS  FGN-PRIMI TIVE-LIBRARY-KB) 

♦Unit  (INITIAL -STRUCTURES  FSH-PRIMI TIVE-LIBRARY-KB) ) 


Unit:  HCPIP 
Menbers:  NIL 
Subclasses:  NIL 


Unit:  HOSTOUT 
Members:  NIL 
Subclasses:  NIL 


Unit:  INITIAL-STRUCTURES 

Menbers:  (((Unit  (CURSOR  FGN-PRIMI  TIVE-LIBRARY-KB) 
♦Unit  (PICK. LOCATION  FGN-PRIMI TIVE-LIBRARY-KB)) 
Subclasses:  NIL 


Unit:  INPUT-FUNCTIONS 

Menbers:  (lUnit  (DIALS  F6N-PRIMITIVE-L IBRARY-KB) 
♦Unit  (BUTTQNSIN  FGN-PRIMI TIVE-LIBRARY-KB) 
♦Unit  (TABLETOUT  FGN-PRIMITI VE-L IBRARY-KB) 
♦Unit  (TABLETIN  FGN-PRIMI TIVE-LIBRARY-KB) 
♦Unit  (SPECKEYS  FGN-PRIMI T I VE-L 1 BRAR Y -KB) 
♦Unit  (PICK  FGN-PRIMI T IVE-LIBRAR Y-KE ) 

♦Unit  (KEYBOARD  FGN-PRIMITIVE-LIBRARY-KB) ) 
Subclasses:  NIL 


Unit:  KEYBOARD 
Meabers:  NIL 
Subclasses:  NIL 


Unit;  H I SCELL ANEuUS-FUNC T  IONS 
Henbers!  (fUnit  (F.SYNC  FGM-PR I M I T I VE-L I BRAR Y -KB > 
•Unit  IF.POSITIQN.LINE  FGM-PR  I  (1 1 T I  VE-L  I BRARY  -KB ) 
♦Unit  (F.P1CKINFQ  FGN-PRII11TI VE-LIBRARY-KB) 

•Unit  IF. NOP  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F. FETCH  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F. EDGE. DETECT  FGN-PRIHITIVE-LIBRARY-KB) 
♦Unit  IF. COLOR  FGN-PRIHITIVE-LIBRARY-KB!) 
Subclasses:  MIL 


Unit:  OBJECT -TRANSFORMATION 
Hesbers:  <#Unit  (F.ZROTATE  FGN-PRIHITIVE-LIBRARY-KB) 
♦Unit  (F.YROTATE  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.XROTATE  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F. SCALE  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (F.DZROTATE  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.DYROTATE  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.DXRQTATE  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (F.DSCALE  FGN-PRIHITIVE-LIBRARY-KB)) 
Subclasses:  NIL 


Unit:  QFF8UTT0NLIGHTS 
Hesbers:  NIL 
Subclasses:  NIL 


Unit:  OUTPUT-FUNCTIONS 

Henbersi  UUnit  (OFFBUT 1 0NL16HT S  FGN-PRIHI II VE-LIBRARY-KB) 
•Unit  (HQSTOUr  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  iHCPIP  FGN-PRIHITIVE-L18RARY-KBI 
♦Unit  (FLABELB  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (FLABEL. 1-12  FGN-PRIHITIVE-LIBRARY-KB) 

♦Unit  (FKEYS  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (FFPLOT  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (DLABEL.1-8  FGN-PRIHITIVE-LIBRARY-KB) 

•Unit  (CLEAR. LABELS  F6N-PRIHITIVE-LIBRARY-KB) ) 
Subclasses:  NIL 


Unit:  PICK 
flenbers:  NIL 
Subclasses;  NIL 
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Unit:  Pick. LOCATION 
Nenbers:  NIL 
Subclasses:  NIL 


Unit:  ROBOT- ARM 
Nenbers:  NIL 
Subclasses:  NIL 


Unit:  SPECKEYS 
Nenbers:  NIL 
Subclasses:  NIL 


Unit:  TABLETIN 
Nenbers:  NIL 
Subclasses:  NIL 


Unit:  TABLETOUT 
Nenbers;  NIL 
Subclasses:  NIL 


Unit:  T1NING 

Nenbers:  (iUmt  (F.T1NEQU!  F6N-PRIHI TIVE-LIBRftRY-KB) 
♦Unit  (F.CLTICKS  FGN-PRINITIVE-LIBRARY-KB! 
tUnit  (F.CLFRANES  FGN-PRINITIVE-LIBRARY-KB! 
lUnit  IF.CLCSECONDS  FGN-PRINITIVE-LIBRARY-KB)) 
Subclasses:  NIL 


Unit:  VIEW- TRANSFORMA T I OM 

Nenbers:  (lUnit  (F.NINBON  FGN-PRINITIVE-LIBRARY-KB) 
•Unit  (F.LQQKFRQH  FGN-PRINITIVE-LIBRARY-KB) 
lUnit  (F.LOOKAT  FGN-PRINITIVE-LIBRARY-KB) 

•Unit  (F.FOV  FGN-PRINITIVE-LIBRARY-KB); 
Subclasses:  NIL 


ADDendix  B:  GraDh  Desisn  Assistant  Source  Code 


The  section  contains  listings  Lisp  code  used  in  the 
Graph  Design  Assistant.  There  are  three  files.  Each  file 
starts  with  a  file  header  and  a  listing  of  the  file's 
contents . 


;;  (lode;  LISP*.  Packaoe:  kEE:  Base:  10 


Filenaae:  qda. lisp 

Protect;  Graoh  Desiqn  Assistant  version  8 

Date;  December  3.  1985 

Author:  Alan  J.  Black 

Description: 

Contains  aisc.  lisp  functions  used  bv  the  the  orach  design  assistant. 


Contents: 


*host-dir» 

variable 

»ada-kbs* 

variable 

qda 

functions 

load-oda-kbs 

function 

save-qda-kbs 

function 

select-froa-alist 

function 

cet-confiraation 

function 

GDA  olobal  variables 

»host-dir*  -  host  directory  for  GDA  svstea 
»qda-kbs*  -  list  of  KEE  databases  in  the  GDA  svstea 

(defvar  *host-dir*  *>black)qda>") 

(defvar  »oda-kb$* 

'( 

ada-svste« 

fqn-araaaar-kb 

fon-priaitive-librarv-kb 

)) 

qda  0  function 

Initializes  GDA.  Loads  files  and  knoaledoe  bases.  Sets  KEE  variables, 
(defun  oda  0 

(load  ‘ ; bl ac k ; oda )or aph-ni ndou" ) 

(load  ’ >bl ack  >qda>i nterf ace-aanaqer ’ ) 


(load-oda-kbs) 

(princ  "Graph  Design  Assistant  loaded") 
(setq  valuedasscheck  ’strict)) 


i  load-gda-kbs 

I 

;  Loads  the  6DA  knowledge  bases 

♦ 

(detun  load-qda-kbs  0 
Idol i st  (kb  *qda-kbs*) 

(kbload  (string-append  ‘host -dir*  (get-pnaee  kb))))) 

i  save-gda-kbs 

I  Save  the  GDA  knowledge  bases 

(defun  save-oda-kbs  0 

(dolist  (kb  *oda-kbs*) 

(kbsave  kb  nil  »host-dir*) ) ) 


select-froa-alist  (alist  ^optional  label) 

displays  a  list  of  available  units  and  allows  the  user  to  choose 
frj»  the  list. 

The  avail able-uni ts-1 ist  is  an  association  list  toriated  as  follows: 

((“label  1"  .  value-1) 

("label  2“  .  value-2) 


(defun  select-froa-alist  (alist  ^optional  label) 
(declare  (special  aenu-window  aenu-list)) 

(setq  aenu-list  nil) 

(setq  aenu-window 
(tv:aake-window 
’tvldvnaaic-aoaentarv-aenu 
borders  2 

:default-font  fonts: hi  1^ 

: label  label 

ideexoosed-tvpeout-action  :perait 
: i te«-l i st-pointer  ’aenu-list)) 

(setq  aenu-list  alist! 

(send  aenu-window  ’.choose)) 


\  *  s  \ 


<  get-conf iraation  (proaot! 

I 

I  Displays  a  «eu  and  asks  the  user  to  confira  a  pending  action 

I 

(defun  qet-conf ir#dtion  (proept) 

(declare  (special  confira-aindo*  confira-aiist)) 

(setq  confira-aiist  nil) 

(setg  conf»ra-t*indo* 

(tvlaake-HindoM 
’tv:dvnaaic-aoaentarv-aenu 
: borders  2 

:def aul t-f ont  fontslhlld 
: label  "CONFIRM:" 

:deexoosed-tvpeout-action  ;oerai t 
: i tea-1 » st-pointer  ’ conf if a-al i st ) ) 

(setq  confira-aiist  '((.proapt  .  .t)  ("abort"  .  .nil))) 

(send  conf ira-MindoN  : choose) ) 


;;  -t-  Mode:  LISP*  Base:  IB:  Package;  KEE  -*- 

File  naae;  oraph-window.lisp 

Protect;  Graph  Design  Assistant,  version  8 

Date:  December  3,  19S5 

Author:  Alan  J.  Black 

Description: 

Contains  the  definition  for  the  graph-window-flavor  and  its 
associated  methods.  The  graph-window-flavor  is  the  tvoe  of 
window  which  is  used  to  edit  graphs  in  GDA. 

Contents: 


oraph-window-flavor 
tvoeout-wi ndow-f 1 avor 
:calc-box-size 
! draw-arc 
: draw-box 
:draw-connector 
:draw-hne-between-points 
Idraw-node 
dra»-io-pair 
make-io-pair-list 
calc-box-width 
calc-box -height 
: draw-selectable-string 
:get-instantiate-location 
:label-graph-window 
:  update-path 
: show-menu 
: update 
: user-message 
initial-gw-item-hst 
make-graph -window 
make-tvoeout-window 


flavor  definition 
flavor  definition 
oraph-window-flavor  method 
oraph-window-fiavor  method 
oraph-window-flavor  method 
graph-wmdow-flavor  method 
graph-window-flavor  method 
graph-window-flavor  method 
function 
function 
function 
function 

graph-window-flavor  method 
graoh-window-flavor  method 
oraph-window-flavor  method 
graoh-window-flavor  method 
graph-window-flavor  method 
graph-window-flavor  method 
graph-window-flavor  method 
function 
function 
function 


oraph-window-flavor 

Flavor  definition,  "klkwin*  is  the  window  flavor  used  bv  KEE.  mixing  in 
oives  the  graoh-window-flavor  similar  properties. 


(def flavor  oraph-window-flavor  t) 


(tvlbasic-eouse-sensitive-iteas 
tv: hi ndoH-Hi th-tvpeout-aixin 
tv:select-»ixin 
kiknin) 

igettable-instance-variables 
: settabie-i nstance-vari ablest 

:  tvoeout-Hindon-flayor 

>  This  Htndott  Hill  allow  for  errors  to  tvpe  out 

(defflavor  tvpeout-Hindon-flavor  0 
(tvIteaoorarv-tvoeout-Hindoa 
tv:select-aixin)l 

i  sene  constants  that  affect  the  Graphic  figures  displayed  in 
:  the  araph-HindOH 

(defconst  line-space  12) 
idefconst  v-connect-ooint-offset  5) 

(defconst  box-too-aargin  2) 

(defconst  box-bottoa-aarain  2) 

(defconst  ain-box-nidth  3#) 

(defconst  am-box-height  3d) 


;  : c al c -box -size  (node) 

I 

:  Calculate  the  sice  of  a  node  box 

I 

(defaethod  (araph-aindon-flavor  ;calc-box-size)  (node) 

(let* 

((input-units  (get. values  node  ’sub-inout)) 

(output-units  (get. values  node  ’ sub-output) ) 

(in-firstnaaes  (aapcar  IMlaabda  (u)  (get, value  u  ’firs inane) )  input-units)) 
(out-firstnaaes  (aapcar  IMlaabda  (u)  (aet, value  u  ’firstnaae))  output-units)) 
(label  (get. value  node  ’label)) 

(box-nidth  (calc-box-Hidth  self  label  in-firstnaaes  out-firstnaaes)) 
(box-height  (calc-box-height  in-firstnaaes  out-firstnaaes))) 

M.box-nidth  .box-height))) 

:  :dran-arc  (arc) 

•  Oran  an  arc 

(defaethod  (oraph-Hindon-flavor  : draw-arc)  (arc) 

(let* 

Kfroa  (oet. value  arc  ’froa-iunction)) 

(to  (get. value  arc  ’to-iunction) ) 
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a V-’.'vV-'tv 


(Cl  loet. value  tro*  'output-position)) 

io2  (set. value  to  ’input-position)) 

(path  (pet. values  arc  ’path))) 

(if 

path 

(send  self  : draw-1 1 ne-between-pos nts  M.pl  .gpath  ,p2i) 

(send  self  idraw-line-between-points  M.pl  fo2>))>) 

I 

<  :draw-box  tx  v  height  width  alu) 

:  Draw  a  box 

% 

(defeethod  tgraph-window-flavor  :draw-box)  lx  v  height  width  ^optional  (alu  tv: alu-ior ) ) 
(let* 

((If  x) 

trt  (♦  x  width)) 

(too  v) 

(bot  (  +  v  height))) 

(send  self  ‘.draw-lines  alu  If  top  rt  top  rt  bot  If  bot  1*  too)) 

(send  self  iset-cursorpos  x  v ) ) 

(defun  xpos  (position)  (first  position)) 

(defun  vpos  (position)  (second  oosition)) 

•  **  *  *  v4-«*‘Va**4r'VV'9*>*%*VV-«4r*  >>  -V-V‘V*'V\V'Vi  -v-V  *  V  v  *V  *  'V  -V  <V 

i  :draw-connector  (connector  inout-p) 

(defeethod  (oraph-window-f lavor  : draw-connector)  (connector) 

(let* 

(tpos  (get. value  connector  'position)) 

(x  (xpos  oos) ) 

(v  (vpos  pos)) 

(firstnaee  (get. value  connector  ’firstnane)! 

(input-o  (qet. value  connector  ’input-p)) 

(shape  (get. values  connector  ’shape)! 

(connect-ooint-offset  (get. value  connector  ’connect-point-offset)) 

(connect-ooint  M,(*x  (xpos  connect-point-offset)) 

.<♦  y  (vpos  connect-point-offset)))) 

(label  (get. value  connector  ’label)) 

(label-offset  (get. value  connector  ’label-offset)) 

(points 

(lapcar  t’daabda  (oomt)  M.(+  x  (xpos  point))  .(+  v  (vpos  point)))) 
shape) ) 

iline-arqs  M.tvlalu-ior  .^(flatten  points)))) 

(if 

inout-p 

(put. value  connector  'output-position  connect-point) 

(out. value  connector  ’ input-position  connect-ooint!) 

(send  self  iset-cursoroos  x  (-  v  line-space)) 

(send  self  idraw-selectable-strinq 


(foreat  nil  ‘va“  firstnaae) 

lif  input-p  Iin-connector-ite#  :out-connector-ite«)  connector) 
(iexor-send  self  : draw-lines  line-args) 

(send  self  :set-cursoroas  (♦  x  (xpos  label-offset))  (  +  v  tvpos  label-offset))) 
(send  self  : str ino-out  label!)) 

l*<V*************************'V******  ******* 

»  :draw-line-between-ooints  (ooint-list  iootional  (alu  tvlalu-ior)) 

( def method  (graph-window-flavor  :draw-line-between-points! 

(point-list  ^optional  (alu  tv: alu-ior > > 

(let 

(lline-arps  '(.alu  . S (f 1 atten-poi nt-1 i st  point-list)))! 

(Iexor-send  self  Idraw-lines  line-aros) ) ) 


idefun  flatten-ooint-list  (point-list! 

(if 

point-list 

(let* 

i ( o 1  (car  point-list))) 

(if 

Pi 

(let 

( (x  (first  pi)) 

(v  (second  pi))) 

(cons  x  (cons  v  (flatten-point-list  (cdr  point-list))))) 
(flatten-ooint-list  (cdr  point-list)))))) 


****** 


***** 


(draw-node  (node) 


Draws  a  node  with  labels  and  io-pins 


defaethod  (oraph-window-flavor  : draw-node)  (node) 

(let* 

((position  (get. value  node  ’position)) 

(x  (first  position)) 

(v  (second  position)) 

(input-units  (get. values  node  ’sub-input!) 

(output-units  (get. values  node  ’sub-output!) 

dn-firstnaees  (eaocar  i’daebda  (u)  (aet. value  u  ’firstnaae))  input-units)) 
lout-firstna#es  iaapcar  i’daabda  (u)  (get. value  u  'firstnaae))  output -units)) 
(node-firstnaae  (oet. value  node  ’firstnaae!) 
label  (get. value  node  ’label)) 

ibox-width  (calc-box-width  self  label  in-firstnaaes  out-firstnanesl) 
(box-height  (calc-box-height  in-f irstnaaes  out-f lrstnaaes) ) 
dteatvpe  (get. value  node  ’selectable-itea-Upe) ) ) 

(send  self  :draw-box  x  v  box-heiaht  box-width) 

(send  self  :set-cursoroos  x  (-  v  line-space)) 

(send  self  ’.draw-selectable-string 


Iforaat  nil  '’'a"  node-firstnaae)  iteatvpe  node) 


(send  self  *■  set-cur sorpos  x  (setq  v  f ♦  v  box-top-*arqin) ) I 
(if  label 
(let* 

(ilabel-lenqth  (send  self  Istrinq-lenqth  label)) 

(1-x  (*  x  U!  !-  box-width  label-lenoth)  2)))> 

(send  self  iset-cursorpos  1-x  v) 

(send  self  : stri no-out  label1 
(setq  v  (*  v  line-space)))) 

(dolist 

(iopair  t»ake-io-pai r-1 1st  incut-units  output -units) ) 
(draw-io-pair  x  v  box-width  iooair  self) 

(setq  v  <  +  v  line-space))))) 


(defun  draw-io-pair  (x  v  box-width  io-pair  window) 

(let 

i 'in-unit  (car  io-pair)> 

(out-unit  (cdr  io-pair) ) > 

(if  in-unit 
(let 

((in-na»e  (oet. value  in-unit  ’firstnaael) 

(connect-pos  ' < . x  ,(♦  v  v-connect-oomt-off set) )) ) 
lout. value  in-unit  ’ input-oosition  connect-oos) 

(send  window  iset-cursorpos  x  v) 

(send  window  idraw-selectable-strinq 

tforeat  nil  *  'a  “  in-na«e)  :inout-ite«  in-unit')) 

(if  out-unit 
(let* 

iiout-nane  <  qet  -  value  out-unit  ’firstnate)) 

(out-strino  (fomat  nil  "  'a  ’  out -na*e> * 
lout-lenoth  Isend  window  : str i no-1 enoth  out-strino)) 

(out-x-offset  l-  box-width  out-1  enoth ) ) 

(connect-oos  '(.(♦  x  box-width)  . (+  v  v-connect-point-c-iiset? ) ! ) 
(out. value  out-unit  ' outout -posi t i on  connect-oos) 

(send  window  iset-cursorpos  (♦  x  out-x-offset'  *> 
isend  window  idraw-selectable-strinq 

out-strino  ioutput-itee  out-unit))))) 

(defun  «ake-io-oair-list  (in-list  out-list) 

(cond 

((and  (null  in-list)  (null  out-1 1 st) )  nil) 

((null  in-list) 

(cons  (cons  nil  (car  out-list))  i»ake-io-oair-Jist  nil  (cdr  out-list)!)) 
I  (null  out-list) 

(cons  (cons  (car  in-list)  nil)  Uake-io-oair-list  (cdr  in-list)  nil))) 

i  4 
\  V 

(cons  (cons  (car  in-list)  (car  out-list)) 

(•ake-io-oair-1 ist  (cdr  in-list)  (cdr  out-list)')))) 

(defun  calc-box-width  (window  label  in-firstna#es  out-firstna#es) 


1%  . 
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(Tv-: 
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nV 
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((io-oairs  Ipairhs  m-f irstnaaes  out-f i rstnaaes) ) 
(gair-widths 
(mapcar 

f’ (lambda  do-pair) 

(let* 

Min-name  (car  io-oair)> 
lout-name  (cdr  10-pair) ) 

(out-width  (it  out-na»e 


(send  window  : str 1  no-1 enoth  (forest  nil  "  'a  ”  out-na«e)i 


0)) 


(in-width  (if  in-name 

(send  window  : str 1  no-1 ength  (forest  nil  "  va  "  in-name)) 
fit)) 

(+  out-width  in-width) i i 
io-oairs>) 

'max-io-pair-width  (if  pair-widths  (apply  ’sax  pair-widths)  it', 

(label-width  (send  window  istrino-ienath  (forest  nil  *  ‘a  *  label); n 
(max  max-io-pair-width  label-width  min-box-width))) 


(defun  calc-boK-heipht  (  in-firstnaaes  out-tirstnames) 

(let* 

I  (max-names  (max  (length  in-f irstnames)  *  1  enoth  out-firstnames) ) ) I 
(Rax  «i n-bow -height 

<♦  box-tog-margin  line-space  (*  max-names  line-space')))) 


'V\VV‘V'»**'V'V*'VV 


hr  \  hr  *V  \  -V 
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idraw-selectable-strina  (string  itestvpe  ite») 


Draws  a  selectaole  string  and  adds  the  ite§  to  the 
itew  al l st. 


(defiethod  (graph-window-flavor  Idraw-selectable-strmo)  (string  itestvpe  i tea) 
(let  (x0  vd  xl  vl) 

(multiple-value  U0  viM  (send  seif  iread-cursorpos) ) 

(send  self  : string-out  string) 

(multiple-value  (xl  vl)  (send  self  Iread-cursorcos) ) 

(send  self  leriaitive-item  iteitvpe  ite*  x0  v$  x!  (♦  v0  10)))) 


V  hr  -v  V  * 


hhhVhhhV  V 


hr  K  \  \  V  hr  hr 


h»hrhfhr\*»'«rVm» 


(oet-instantiate-location 

Allows  user  to  move  point  to  a  position  in  the  window  with  the  mouse. 
Returns;  coordinates  U  v).  or  nil  if  user  aborts 


(defmethod  (oraph-window-f lavor  :qet-location)  (width  height' 
(send  self  lexoose' 
ltv;*ouse-wait) 

I  tv: wi th-mouse-grabbed-on-Sheet  ( ' 

(do 
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•  ’>  V  •  «  •  V  v 


.vWV 

•  y  .• 


-v 

.V.N*  ' 


-*  -K  .A 


t(x  (-  tvtaouse-x  8)  (-  tv:«ouse-x  8)) 

(v  I-  tv;»ouse-v  24)  (-  tv:*ouse-v  24)) 

(b  tvlaouse-last-buttons  tv.nouse-last -buttons!) 

Uneq  b  9)  (if  fs  b  1)  (list  x  v)  nil)) 

(draw-locate-box  self  x  v  width  heioht) 

(send  self  : user -«es sage  (foraat  nil  'L.'Locate.  R: Abort  x:v4d  v:"4d" 
(tvlaouse-wait) 

(draw-locate-box  self  x  v  width  height)))) 

(defun  draw-locate-box  (window  x0  v0  width  height) 

(let 

( (Ml  <+  x$i  width)) 

(vl  («■  v0  height))) 

(send  window  ;draw-lines  tvlalu-xor  xU  v0  xl  v0  xl  vl  x8  vl  x3  v0)D 


i  .‘la bel -graph-window  current-graph 

(defaethod  (graph-window-flavor  : 1 abel -graph-wi ndow)  (current-graph) 

(let  (graphnaae  kbnane) 

(cond 

(current-graph 

(seto  graphnaae  (unit.naae  current-graph)) 

(setq  kbnaae  (kb.naae  (unit. kb  current-graph)))) 

(t 

(setq  oraphnaae  "not  assigned'1) 

(setq  kbnaae  "not  assigned"))) 

(send  self  ; set-label 

(foraat  nil  "qraoh;  'a  kb:  'a"  graphnaae  kbnaae)!') 

%  \  K-  *  \  *  \  v  A,  *  K  *  *  \  >  \  *  -V  «,  \  \  \  •*  K  V  \  %  V  \  \  *■  '*  +  *  ».  \ 

luodate-path  (pi  nath  p2) 

defaethod  (araph-window-f lavor  ; update-path )  (pi  path  p2) 

(send  self  lexpose) 

(send  self  :draw-line-between-points  '(.pi  ,8path  ,pl)  tvlalu-xor' 

(tv: ai th-aouse-grabbed-on-sheet  ( ) 

(tvlaouse-wait) 

(do 

( (quit  nil) 

(new-path  nil) 

(xl  (first  pi)) 

(vl  (second  pi)) 

(x  (-  tvlaouse-x  8)  (-  tv:»ouse-x  8)) 

(v  (-  tv:aouse-v  24)  (-  tv:»ouse-v  24)) 

(b  tvlaouse-last-buttons  tv:»ouse-l ast-buttons) ? 

(quit 

(send  seif  Idraw-line-between-ooints  '(.pi  ,8new-path  . pZ) ! 
new-path) 


(seleciq  b 

(1  (send  self  : dra»-l i ne-between-points  '(.pi  . @new-path)  tv:alu-xor) 
(setq  new-path  (append  new-path  '((.*  , v) ) ) ) 

(send  sell  Idraw-line-between-points  M.pl  ,8new-oath)  tvlalu-xor) 
(setq  xl  x) 

(setq  vl  v) > 

(2 

(setq  new-path  (butlast  new-path) ) 

(il  new-path 
(let 

((last-point  (first  (last  new-path) ) ) ) 

(send  self  :draw-line-between-ooints 

'(.last-ooint  (,xl  ,vl>)  tv.'alu-xor) 

(setq  xl  (first  last-point)) 

(setq  vl  (second  last-point))) 
ioroon 

(send  self  Idraw-line-between-DQints 
'(.pi  (,xl  ,vl))  tvlalu-xor) 

(setq  xl  (first  oD) 

(setq  vl  (second  pi))))) 

14  (seta  quit  t))) 

(send  self  idraw-hne-betweEn-ooints  '((.xl  . 1 )  t.x  . v)  ,o 2)  tvlaiu-xor! 
(send  self  luser-aessaae 
(fornat  ml 

*L: add-poi nt  L;delete-last-point  Rlexit  t'4d.v4d)  i'4d.v4d) 
(tvlaouse-wait) 

(send  self  :draw-l i ne-between-points  'li.xl  .vl)  (,x  .»)  ,o2)  tvlalu-xor) 


\  v  V  V  ',  v  y  V  v  -V  -v  "V  >  -V  V  X#  "v  -V  -V  V  -V  •»  -V  -V  -v  v  *  V  >  N  V  V  V  v  -v 

!set-cursorpos-rel 

defeethod  (araph-window-tlavor  : set-cur sorsos-rei)  -d-v  d-v) 

(let  ts  v) 

Uultiole-value  U  v)  (send  self  ;  read-cursor  bos)  ) 

(send  self  Iset-cursoroos  (f  x  d-x)  i*  v  d-v)!!; 


! snow-flenu 


;  Writes  the  list  of  menu  items  across  the  too  of  the  mndow 

•  deuetbod  (srast'-windoM-tlavor  ;sho«-«enu>  w 
send  sei*  iset-cursoroos  3  2> 

■xaocar 

*’ (iaabda  (arc. 

'lexor-senc  sei*  sr'o- 

'send  self  Istrir.c-out  1  " : 

IlteW  . iienU.- COOw  Q'.-t  'lOOw-Out  1 

1 1  teti  \  :xenu-Hi  'too*  "»indo«  ' 
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Cite*  laenti-aaenda 
Cite*  ;*enu-craph 
Cites  :*enu-olen 
Cite*  ;senu-priiitive 
Cite*  ;*efiu-iunction 


: uGdate  orach  kb 

de^ aethod  (qraph-wi ndow-f  1  a v'O 
(send  self  Idear-window) 
(send  self  :sho«r«enu) 
(send  seif  ‘.label -orach-* 


"agenda") 
"orach"  ■ 
"plan") 
"prinitire") 
0 i unction") 


\  \  »  *•»  "V  \  ■,  *»  *.  ,  V  %  'ir 


; update)  (current-orach) 


ndow  current-oraph!) 


«*f'«  >'»  VVVV*f'v%VVn>V  -v'V‘V*»  V  VVSV\%‘V'V*<\V-V'\><VV«V'V«'«»*»VN>V 

<  luser-messaoe  ■aessaae  string) 

i 

5  Displays  the  nessage  in  the  loner  left  corner  of  the  window 

t 

'deftethod  Igraoh-window-flavor  luser-eessage)  (sessage-string) 

(send  self  :ho«e-downl 
(send  self  Idear-rest-of-line) 

(send  self  Istring-out  »essage-strino) ! 

•  *<»NV*%V<VV\aU<VV*V'YN'V4.'VV  V\<V*.'W>VN*.\VV<V’V'N'<V'V'l>  +  %*.<V'VVlV 

!  mtial-gw-iten-alist 
» 

i  This  function  initializes  the  ite*  alist  for  the  graph-window 
» 

(defun  initial -oh-i ten-all st  0 
(let  ! (gw-itet-alist  nil)) 

! tv :add-tvpeout-i ten-type 
g»-ite»-alist 
;*enu-zoo«-out 
"zoot-out" 

;:oo*-out 

* 

v 

"Zoo*  out  and  view  parent  of  this  graph”) 

:  -  «enu-window  iteas  — 


(tv’.add-tvpaout-i  ten-type 
gw-ite*-alist 
:*enu-window 
"assign-graph" 
lassion-graph 
nil 

"fissions  a  orach  to  this  window") 
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:«enu-MindcM 

“update-window” 

: update-window 

t 

“Redraw  the  window”) 

'  aenu-agenda  items  — 

i tv: add-tvpeout-i tea-type 
gw-itea-alist 
: aenu-agenda 
“describe-agenda-ite*" 

:describe-apenda-itea 

nil 

"Shows  a  description  of  an  itea  that  is  on  the  aaenda") 

!tv:add-tvpeout-itea-tvae 
gw-itea-aJist 
: aenu-agenda 
"delete-apenda-itea" 

'.delete- agenda-ire* 
mi 

“Deletes  an  itea  froa  the  agenda  without  executing  it"! 

<  t v : add-t  vpeout-i tea-type 
gw-itea-alist 
:»enu-aoenda 
”select-agenda-ite»'‘ 

:select-agenda-itea 

t 

“Selects  an  itea  fro#  the  agenda  to  execute") 

-  aenu-graph  items  — 


(tv: add-tvpeout-i tea-type 
gw-itea-alist 
:aenu-graph 
“create-graoh" 

:create-graph 

nil 

"Create  a  araph.  independent  of  the  graph  assigned  to  this  window") 

(tvladd-tvoeout-itea-tvoe 

gw-itea-alist 

:aenu-graoh 

"create-sub-graph’ 

:create-sub-graah 

t 


'Create  a  new  graph  as  a  child  of  the  graph  assigned  to  this  window') 


-  aenu-plan  iteis  — 


(tvladd-tvpeout-itea-tvpe 
ow-itea-alist 
: aenu-plan 
“describe-olan" 

:describe-plan 

nil 

"Shows  a  description  of  a  olan  in  the  olan  library") 

(tvladd-tyoeout-i tea-type 
ow-i tea-ali st 
‘.aenu-plan 
“instantiate-olan" 

: i nstant i ate-pl an 
t 

"Gets  a  plan  froa  the  library  and  instantiates  it  as  the  child  of  the  assigned  graph") 


—  aenu-pnaitive  i teats  — 

itviadd-tvpeout-itea-tvpe 
gw-itea-alist 
:aenu-oriaitive 
"describe-priaitive11 
: descr i be-pr i *1 ti ye 
nil 

"Shows  a  description  of  a  pnaitive  in  the  priaitive  library") 


(tv.  add-tvoeout-i  tea-type 
gw-itea-alist 
laenu-priaitive 
"instantiate-pnaitive” 
linstantiate-priaitive 
t 

"Gets  a  library  priaitiye  and  instantiaties  as  the  child  of  the  assioned  graph") 


—  aenu-iunction  - 


(tv: add-tvpeout-i tea-tvpe 
gw-itea-alist 
iaenu-iunction 
“instantiate-iunction* 

: instanti ate- junction 
t 


V  /  V  •>  * 
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V 


"Instantiate  a  junction  tor  external  connections") 


;  —  qraoh-ite*  — 

itv:add-tvpeout-ite#-tvpe 
g*-ite«-alist 
: graph-i  te* 

“iabel-graph" 

:  label -graph 
nil 

"Assign  a  label  to  this  graph  (displayed  inside  box)") 

(tv: add-typeout-i te*-tyoe 
ge-item-alist 
: graph-i te* 

"rename-graph* 

: rename-element 
ml 

"Renames  this  graph  node") 

I  tvladd-tvpeout-i tern-type 
am-item-alist 
:  graph-i te« 

“delete-graph" 

: delete-el e»ent 
nil 

■Deletes  this  graph  node  and  all  it’s  children") 

(tvladd-tvpeout-item-tvpe 
g*ritem-alist 
: graph-i te« 

":oo*-in" 

: zoom-in 
t 

'Zoo*  in  on  this  oraph  node") 


—  primitive-item  — 

(tvladd-tvpeout-itee-tvpe 

g*rite*-aiist 

loruitive-ite* 

"delete-primitive" 

:delete-ele»ent 

nil 

"Delete  this  ormitive  node") 


(tvladd-tvoeout-itee-tvoe 

om-item-alist 


“renaae-oriaitive" 

’.renaae-eleaent 

nil 

"Renaae  this  primitive  node") 

-  in-connector-itea  — 

itviadd-tvpeout-itea-tvpe 

gu-itea-alist 

:in-connector-itei 

"renaae-out-connector" 

‘.renaae-eleaent 

nil 

"Renaae  this  in-connector") 

(tviadd-tvoeout-itea-tvpe 

gw-itea-alist 

:in-connector-ite# 

“delete-connector" 

: delete-el e®ent 
nil 

’Delete  connection  node") 

<tv: add-tvpeout-i tee-tvpe 
g*-itea-alist 
: input*i tes 
“delete-out-arc" 

:delete-out-arc 

ml 

"Delete  an  out  arc") 

ttvladd-tvoeout-itea-tvce 

gn-itea-alist 

:in-connector-itea 

"aoditv-out-arc-oath" 

‘.aodifv-out-arc-path 

ml 

‘Change  the  path  of  the  arc") 

:t*:add-tvpeout-itea-tvpe 
om-i tea-all st 
;  in-connector-ite# 

'arc-start" 

:arc-start 

t 

’Start  a  connection  arc1') 


out-connector-itea 


qa-itea-alist 

;out-connector-itea 

"renaae-out-connector* 

:renaae-eleaent 

nil 

"Renaae  this  out -connector"! 

( tv: add-tvoeout-i tea-type 
ga-itea-alist 
:out-connector-ites 
"delete-connector" 
:delete-eleaent 
nil 

'Delete  connection  node") 

(tv: add-tvpeout-i tea-type 
qa-itea-alist 
:out-connector-itea 
"arc-coaplete" 

:arc-coaplete 

t 

"Start  a  connection  arc") 


-  inout-itea 

(tviadd-tvpeout-itea-tvpe 
qti-itea-alist 
:  input-i tea 
"renaae-input" 

Irenaae-eleaent 

nil 

"Renaae  this  mout") 


Itvladd-tvpeout-itea-tvoe 
aa-itea-alist 
; inout-itea 
"arc-coaplete" 

: arc-coaplete 
t 

“Coaplete  a  connection  arc") 

-  output -i tern 

<  tv’,  add-tvpeout-i  ten-type 
ON-itea-alist 
: output-i tea 
"renaae-output" 
irenaae-eleaent 
nil 


Renaae  this  output") 


(tvUdd-trpecut-i  tee-type 
ow-itee-alist 
: output-i tea 
"delete-out-arc" 
:delete-out-arc 
nil 

"Delete  an  in  arc") 

I tvladd-typeout-i tee-type 
gw-itea-alist 
: output-i tea 
"»odifv-out-arc-path" 
;»odifv-out-arc-Dath 
nil 

"Change  the  path  of  the  arc") 

( t  v:  add-tvpeout-i  tea-tvpe 
qw-itee-alist 
:outout-ite* 

“arc-start" 

:  arc-start 
t 

‘Start  a  connection  arc") 


;  —  end  Qf  tvpeout  ite#  tvoes  — 

qw-itee-alist); 

!  eake-graon-wmdow 

i  Creates  a  new  graph  window  an  starts  a  graph  window  process, 

i  returns:  :eta  window  object 

(defun  eake-aranh-window  (ites-alist) 

(tv.eake-window 
'oraph-window-flavor 
Mabel  "Graph  Window" 

:edges-fro*  leouse 
leMoose-p  t 
:save-bits  t 
Iblinker-o  nil 

Mte»-tvpe-alist  ite«-alist!) 

•  '«  Wf  S  v  %  N  \  m  %  V  V  ■*  \  %  *  V  N  N  v  ^  S  V  V  V  V  ■*  >  *V  •'»  **  \  <V  *v  V  %  \  v  \  *  \  \ 

:  eake-tvpeout-window 
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(defun  nake-tvpeout -window  (super ior-wndow> 
(tv:*ake-»*indo« 

'tvpeout-uindoH-flavor 
(superior  suoenor-ttindOH) ) 


( cowl  1  e-f  1 a vor-eethods  oraoh-wi ndo*-»  1  avor ) 
(co»pile-flavor-»ethods  tvoeout-»indot*-flavor i 
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-«-  Hods:  USF;  Base:  IB;  Package:  kEE  -*- 

File  na«e:  interface-»anager.lisp 

Protect:  Graph  Design  Assistant,  version  B 

Date:  Deceeber  3,  1985 

Author;  Alan  J.  Black 

Description; 

Containts  the  ncuse  handler  orocess  which  defines  the  user  interface 
to  a  orach-window. 

Contents: 

start-oraph-window-orocess  function 

praoh-window-orocess  function 

check-for-teramal-io  function 

Functions  that  execute  user  co«#ands‘. 


arc-cowlete 

function 

arc-start 

function 

assign-graph 

function 

create-graoh 

function 

create-sub-araph 

function 

delete-eieeent 

function 

deJete-out-arc 

function 

instantiate-iunction 

function 

instantiate-orimtive 

function 

•odifv-out-arc-path 

function 

renaae-elewent 

function 

update-oraph-window 

function 

coon- in 

function 

coon-out 

function 

W*.  > 
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start-graoh-window-orocess 

Starts  a  graph  window  orocess 

(defun  start-graoh-window-orocess  U 
(orocess-run-function  M:na»e  “graoh-window-orocess" ) 

I’oraph-window-orocess 

)) 


m 
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(detvar  *gw*)  ;  Contains  the  current  graph-window  object.  for  debugging  purposes 


graph-window-process 

The  process  which  handles  souse  inputs  for  a  window. 

The  function  is  a  loop  which  reads  in  a  souse  ''blip”, 
decodes  it.  then  calls  the  function  requested  bv  the  user. 


i  The  loop  is  endless,  however,  the  user  can  kill  the  process  bv 

.*  closing  the  window  (a  K£E  window  orooertv). 

» 

tdefun  graoh-window-process  0 
(let* 

l (graph  nil) 

(current-out-iunction  nil) 

(ltem-alist  (imtial-gw-ite#-alist) ) 

(window  (sake-graoh-window  itee-alist)) 

(ter«mal-io  (sake-tvpeout-window  window))! 

(tviwindow-souse-call  (window  Ideactivatei 
i set o  *gw*  window)  •  for  debugging 

(okg-goto  ’kee) 

(update-oraph-window  window  graph) 

(error-restart-loop  ((svslabort)  'Restart  oraph-window-process”  ml) 
(check-for-terainal-io  tersinal-io) 

(let* 

Slblio  (send  window  : anv-tvi ) ) 

(cossand  (second  bho)) 

(ob.iect  (third  blio))) 

(send  window  luser-sessage  '  ") 

(if  (and  current-out-iunction  (neo  cossand  larc-cosolete)) 

(seta  current-out-iunction  ml)) 

(selecto  cossand 
Carc-cosolete 
(setq  current-out-iunction 

tarc-cosolete  window  graph  ob.iect  current-out- juncti on' ) ) 
Care-start  (setq  current-out-iunction  (arc-start  window  graoh  object 
C uodate-window 

(update-graph-window  window  graoh)) 

Cassign-graoh 

( seta  graph  (assign-graph  windew  graph))) 

Ccreate-graoh 

(setq  graph  (create-graoh  window  graoh))) 

Ccreate-sub-graoh 
icreate-sub-graoh  window  graph)) 

Cdelete-elesent  (delete-elesent  window  graph  object)) 
Cdelete-out-arc 

(delete-out-arc  window  graph  object)) 

Cinstantiate-junction  (instantiate-umction  window  orach)) 
<:instantiate-orisitive  (instantiate-orisitive  window  oraohi) 


f v-out-arc-oath  l#odifv-out-arc-oath  window  object)) 
Crenawe-eleaent  (renaae-eleaent  window  object  graph)! 
<;:oo»-in  (setq  graph  (jooa-in  window  object))) 

Czooa-out  (setq  graph  (zoos-out  window  graph)!) 

(otherwise 

(send  window  ;user-»essage 

(foraat  nil  "Coaaand  not  iaoleaented:  's'1  blip))))))))) 


\  \  \  \  \  \ 
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check-current-araoh  (window  orach) 


Check  to  see  it  graph  unit  exists,  if  not  disolav  aessage  in 
window  and  return  nil 


detun  check-current-graph  (window  oraoh) 
tcond 

((null  orapn) 

(send  window  :  user -message  (foraat  ml  *A  graph  is  not  assigned  to  this  window11')) 
((null  (uni {reference*  orach)) 

(send  window  iuser-aessaoe  (foraat  ml  "errror:  vs  is  not  a  graoh?"  graph)!) 

!t  orach; ) ) 
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Check  to  see  if  anv  tvoe  out  has  occurred  cm  the  tvoeout  window, 
if  it  has.  wait  until  the  user  is  ready  to  continue. 


(defun  check-kor-terainal-io  (tio) 

(cond 

i (send  tio  lexoosed-o) 

(send  tio  :string-out  ( format  ml  " '"'.cl i ch  aouse  on  window  to  continue")) 
isend  tio  lanv-tvi) 

(send  tio  : deexpose) ) ) ) 


arc-coaolete  (window  graph  in-junction  current-out-junction) 

Completes  an  arc. 

Creates  an  ARC  eleaent  and  places  pointers  in 

it’s  FRGfl- J'JNCT ION  and  10-JUNCTION  slot  of  the  arc  unit. 

Places  pointers  in  the  OUT-ARC  slot  of  the  out  junction,  and  the  IN-ARC 
slot  of  the  in  junction. 

(defun  arc-coaolete  (window  oraoh  in-junction  current-out-junctiom 
( i  f 

(null  current-out- j unct i on ) 

(send  window  luser-aessaoe  "Start  arc  on  an  output  o*  a  node”; 


Marc  (unitmso  graph  ’add-sub-element  ’(arc  pda-system}))) 
(cut, value  arc  ’from-.iunction  current-out-iunction) 

(out. value  arc  'to-iunction  in-iunction) 

(add. value  current-out-.iunction  ’out-arc  arc) 

(add. value  in-iunction  ’in-arc  arc) 

(uodate-araoh-window  window  orach))) 

nil) 

arc-start  (window  graph  out-.iunction) 

Sends  the  user  a  message  that  he  has  started  an  arc. 

Returns  the  out  junction. 


(defun  arc-start  (window  oraph  out  -  tunc ti on i 
(let* 

( (out-oin-nase  (aet. value  out-junction  ’firstname)) 

(oarent-node  (aet. value  out-junction  'suoer-element)' 

(node-name  (get. value  parent-node  ’firstname))) 

(send  window  iuser-nessage 

(format  nil  "Arc  started  from  'a.  'a"  out-pin-name  node-name)) 
out-junction) ) 
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assign-graoh  (window  current-graph) 

Assions  the  araoh  that  is  to  be  displayed  in  the  graph-window. 

The  user  is  presented  with  a  pop-uo  menu  where  he  can  fill  in 

the  name  of  the  graph  and  the  knowledge  base  that  contains  the  araoh. 

Returns  the  unit. reference  to  the  graoh  unless  there  is  an  error,  then 
nil  is  returned. 

defun  assion-graoh  (window  current-graph) 

(declare  (soecial  graoh-name  kb-na*e)) 

(cond 

((null  current -graph) 

( set q  graph-name  nil > 

(seta  kb-na»e  nil)) 

( (uni Inference*  current-graoh) 

(seta  graoh-name  (unit. name  current-praoM ( 

(seta  kb-name  (ko.name  (unit. kb  current-graoh)))). 
‘tvichoose-variable-values 
’((graoh-name  "Graoh  *> 

(kb-name  "knowledgebase"') 

Mabel  "Assign  graoh  to  window  "> 
i  cond 

( < seta  current-orach  (unitreference*  1 ;.oraoh-na*e  .kb-name))) 


(kbooto  kb-naae) 

(send  window  I  label -orach-window  current-uraph) 
current-orach) 
it 

(send  window  luser-aessage 
(foraat 
nil 

"Unit  'a.  knowledoe  base  'a.  does  not  exist  or  is  not  a  orach  unit 
oraph-nane  kb-naae)) 

(send  window  llabel-graph-window  nil) 
ml))) 
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;  create-graph  (window  graph) 

;  Creates  a  new  graph  that  is  not  a  sub-graph, 

!  Asks  user  tor  name  of  a  knew  graph  and  sends  an  INSTANTIATE  aessaoe  to 

;  to  the  class  definition  of  a  graoh—  ’(GRAPH  SDA-SYSTEN), 

!  Returns  the  new  graph’s  unit. reference. 

idefun  create-grach  (window  current-araoh) 

(declare  (special  graph-naae  kb-naue)) 

(cond 

((null  current-graph) 

(seto  graoh-naae  nil) 

(seta  kb-naae  nil)) 

I  (umtreference*  current-graph) 

(seta  kb-naae  (kb.naae  (unit. kb  current-orach)) ))) 

'setg  araoh-naae  ml) 

(tvichoose-variable-values 

( (araoh-naae  ’Graph  ") 

(kb-naae  “Knowledoe  base")) 

Ilabel  "Create  a  new  graoh  *) 

(cond 

( Ikbreference*  kb-naae) 

(kbaoto  kb-naae) 

(seto  current-graph 

(unit*sg  ' (graph  gda-svste»)  ’instantiate)) 

(umtasg  current-graph  'naae-eleaent  oraph-naae) 

(send  window  1  label -or aph-window  current-gr aph) 

(update-graph-window  window  current-graph! 
current-graph) 

(t 

(send  window  iuser-aessaae 
(foraat 
ml 

"Unit  'a.  knowledoe  base  va.  does  not  exist  or  is  not  a  orach  unit” 
araoh-naae  kb-naae) ) 


create-sub-graoh  (window  parentgraph) 


Creates  a  new  graph  which  is  a  sub-graph  o f  the  graph  which  is 
currentlv  being  edited.  The  new  graph  is  given  a  default  nate. 

The  user  is  shown  an  outline  of  the  graph  node  and  asked  to  position 
the  graoh  sotewhere  within  the  graph-window. 

The  graph  is  created  bv  sending  an  ADD-SUB-ELEtlENT  tessape  to 
the  class  definition  of  graoh--’ (GRAPH  6DA-SYSTEM). 


(defun  create-sub-oraph  (window  parent cr aph ) 

(if 

(or  (null  parentgraph) 

(null  (umtreference*  parentaraoh)!) 

(send  window  luser-eessaoe 

"Cannot  create  child  graph  until  a  parent  graph  is  assigned  to  window"! 

(let* 

((subgraph  lunitasg  parentaraoh  'add-sub-eietent  ’(graph  gda-svstet) )) 
(height  (unittsg  subgraph  ’calc-disolav-height  window)) 

(width  (unittsg  subgraph  ’calc-displav-width  window)) 

(location  (send  window  ;qet-location  width  height))' 

(cond 

(location 

(out. value  subgraph  ’position  location) 

(update-graph-window  window  parentgraph) ) 

(t 

(unit «$Q  parentgraph  'retove-sub-eletent  subpraohi!) 


delete-ele»ent  (window  graoh  eletent' 

Deletes  an  eletent. 

"Eletent”  is  the  object  the  user  .s  oointino  to  when  he  selects 
this  function, 

A  ooo-up  tenu  aooears  and  asks  tor  a  confutation  ct  the  delete 
function. 

An  eletent  is  deleted  bv  sendino  a  DELETE  tessape  to  the  elenent. 

(defun  delete-eletent  (window  oraoh  eletent) 

(if 

(aet-confiraaticn  (foriat  nil  "Delete  'a*  lunit.nate  eletent))) 


1 


loroon 

(umtasq  eieaent  ’delete) 
lupdate-qraoh-window  window  orach) .0; 
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;  delete-out-arc  (mi ndow  orach  out-junction/ 

? 

;  Deletes  an  outout  arc. 

;  There  *av  be  nultiple  arcs  that  ennate  fro#  a  single 

i  junction.  therefore  a  SELECT-ARC-Ff?OM-SLOT  nessaoe  is  sent 

>  to  the  out-junction,  This  displavs  a  *enu  of  all  of  the 

;  output  arcs  and  allows  the  user  to  select  which  one  he  wants  to  delete. 

1 

(defun  delete-out-arc  (window  graph  out-junction) 

(let* 

((arc  (unitasg  out-iunction  ’seiect-arc-froarsiot  ’out-arc  "Select  arc  to  delete")) 
(to  (aet. value  arc  ’to-junctioni)) 

(if 

(get-conf ir#ation  iforeat  nil  “Delete  arc  to  'a*  (unit, name  to))) 

(proon 

(unitssa  arc  ’delete) 
lupdate-qraoh-window  window  graph))/)) 
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instantiate-iunction  (window  graoh) 

t 

i  Creates  a  new  instance  of  a  junction. 

1 

;  A  pop-up  aenu  asks  the  user  to  select  either  an  input  or 

!  output  junction. 

! 

:  The  user  is  ask  to  position  the  junction  in  the  graph-window, 

♦ 

i  The  new  junctions  is  created  bv  sending  a  ADD-SUB-ELEMENT  sessaoe 

:  to  the  graoh. 

• 

(defun  instantiate- junction  (window  graph) 

(if 

(check-current-graph  window  oraph) 

(let* 

((avail-classes  ’ ((incut-junction  un-connector  gda-svste®)) 
(output-junction  (out-connector  oda-svstea) ) ) ) 

(class  (seiect-frou-ilist  avail-classes  “Input  or  ouput?">)) 

(if 

class 

(let* 

((junction  (umt*sg  graph  ’ add-sub-el eeent  (umtreference  class))) 
(location  (send  window  loet-location  20  20))) 

(cond 

(location 


«,<  I? 
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(out. value  junction  ’position  location) 
(update-graph-window  window  oraoh) ) 

(t 

(unitaso  graph  ’reaove-sub-eleaent  junction)))))))) 


instant i ate-pr ini ti ve  (window  graph) 

Creates  an  new  instance  of  a  pnaitive. 

Display’s  a  aenu  of  the  priaitive  librarv  aeabers  for  this  type 
of  graph.  If  the  user  selects  a  aeaber.  an  instance  of  that 
class  of  primitives  is  created. 

(defun  mstantiate-oriaitive  (window  graph) 

(if 

(check-current-qraph  window  graph) 

(let* 

((oraaaar  (get. value  graph  ’qraa»er!) 

(librarv  (get. value  oraaaar  ’priaitive-hbrarv) ) 

(newdass  (unitaso  librarv  ’ select-f r oa-aenut) ) 

(if 

newel  ass 
(let* 

((newumt  (unitaso  graph  ’ add-sub-element  newdass)) 

(location  (send  window  :pet-l ocation  30  40))) 

(cond 

(location 

(put. value  newunit  ’position  location) 
(update-graph-window  window  graph)) 

(t 

(unitaso  graph  'reaove-sub-eleaent  newunit)))))))) 


i  aodifv-out-arc-path  (window  froa-junction) 

i  Allows  the  user  the  change  the  path  of  an  arc.  (The  oath  is  the  visual 

;  representation  of  the  arc.  an  arc’s  default  path  is  just  a  straign  line). 

(defun  aodifv-out-arc-path  (window  froa-junction) 

(let 

<  lout-arc  (unitaso  froa-junction  ’seled-arc-froa-slot  'out-arc  “Select  arc  to  aodifv"  ))) 
(if  out-arc 
(let* 

( -to-junction  (get. value  out-arc  ’to-junction) ) 

(pi  (get. value  froa-iunction  ’cutout-position)) 

(o2  (get. value  to-junction  ’incut-position)) 

(old-oath  (get. values  out-arc  ’path)) 

(new-path  (send  window  :uodate-path  pi  old-path  o2))) 

(put. values  out-arc  ’path  new-path) 
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(send  window  ) user -message 

(format  nil  "Hodifv  arc.  old  path;  vs.  new  path:  's“  old-oath  new-path.W)))) 
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rename-element  (window  element  oraph) 

Allows  a  user  to  rename  an  element.  All  new  units  are  pi  yen  a  default 
name  when  thev  are  created,  this  function  allows  the  unit  to  give 
more  meaningful  names. 


Displays  a  file  in  pop-up  menu  that  allows  the  user  to  enter 
the  new  name. 

The  name  of  the  element  is  changed  by  sending  a  NAME-ELEflENT  message 
to  the  element.  This  renames  the  unit  and  all  of  the  sub-elements  of 
the  unit. 

(defun  rename-element  (window  element  graph) 

(declare  (special  name)) 

( seta  name  (get. value  element  ’firstname)) 

(tv:chopse-vanabl  e-values 
'((name  "Element  name")) 

Jlabel  “Rename  element  ") 

(if 

name 

(orogn 

(unitmsg  element  'name-element  name) 
lupdate-graph-window  window  graph) 

(send  window  :user-message  (format  nil  "New  name  'a"  name))) 

(send  window  luser-messaoe  “No  new  name"))) 


A.\\\v**vvvm»w.i»Nw,vm,**\vvv*Vv%-vw,v-v’VV\  'r>v'>'V 

update-graoh-window  (window  graph) 

Redisplays  the  araph-window 

(defun  update-graph-window  (window  graph) 

(send  window  Idear-window! 

(send  window  : show-menu) 

(send  window  : label -graph-window  graph1 
(if 

graph 

lunitmso  graph  ’draw-sub-elements  window))) 

» 

!  zoom-in  (window  newgraph-obiect) 

Returns  the  newgraph-object  to  the  graph-window.  This  allows  the  user 
to  edit  sub-graphs. 
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(defun  zoom-in  (window  newgraph-obiect) 

(update-graph-window  window  neworaph-obiect) 
newgraph-object) 

i  zoom-out  window  oldgraph 

i  Returns  the  parent  graph  (SUPER-ELEMENT),  The  super-element 
;  becomes  the  new  graph  assigned  to  the  graoh-window. 

(defun  zoom-out  (window  oldgraph) 

(if 

(check-current-graph  window  oldgraph) 

(let 

((parent  (get. value  oldgraph  ’super-element))) 

(cond 

(parent 

(uodate-graoh-window  window  parent) 
oarent) 

(t 

(send  window  luser -message 

(format  nil  "Can’t  zoom-out.  'a  is  at  the  top" 
(get. value  oldgraph  ’first-name))) 


oldaraoh))!)) 
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